Current ideas on kerberos requirements for Samba4

[Andrew Tridgell]

Sam,

Perhaps I should explain a bit more what the motivation is for moving
services like ldap and krb5 inside of Samba.

The Samba user community is very diverse. Some of our users are the
sorts of people who are comfortable with setting up and diagnosing
openldap, MIT or heimdal kerberos, FreeDCE etc. The vast majority
would find having to setup all those services a big burden. By
comparison Samba3 is really easy to setup in the way that most people
operate it - which is either as a standalone server or a member of an
existing windows domain.

The motivation for building in a KDC and a LDAP server so it works
'out of the box' is to make life easy for the vast majority of Samba
admins who have never setup kerberos or ldap before. When I first
started on the ADS effort in Samba, I tried to get all the existing
free software tools that implement the various protocols we need to
work together. It took me several days of extreme frustration fighting
with library versions, obscure error messages, protocols sniffs and
new config formats to get to the point that I could make a simple
kerberos authenticated ldapsearch request against a openldap server
authenticated with my own MIT kerberos realm.

It was possible, and it did eventually work, but it was
extraordinarily painful. What was worse was that I was using a
mainstream Linux varient and I was following step by step a howto on
exactly how to set this up. If I tried to reproduce the same result on
IRIX, AIX or Solaris I expect it would have taken far longer.

I knew that if I told the Samba user community 'OK, to use Samba4 you
need to go through all of that' then we would have reduced our user
base by a factor of 100 or more. It is just too arcane.

This is not just ancient history either. I attended a LUG talk a few
weeks ago where the speaker demonstrated (over a period of about two
hours) how to setup openldap with kerberos authentication, including
creating a new realm etc. At the end of the two hours it still wasn't
working.

The users we are aiming for in Samba4 would not know a realm if it hit
them in the face. They probably think a 'distinguished name' is
something given to people in the queens honours list. They certainly
don't know what kind of cheese to ask for in a SPNEGO sandwich :)

In implementing Samba4, we need to get all of the following protocols
to talk together perfectly:

  - SMB/CIFS
  - DCE/RPC over ncacn_np and ncacn_ip_tcp
  - DNS
  - krb5
  - LDAP
  - CLDAP
  - WINS
  - NBT name service
  - NBT datagram service

all of these are interwoven to a high degree, and they need to be
completely coherent with respect to their data storage. When a WinXP
box talks to us, it creates a lump of data with one protocol, queries
that data with a 2nd protocol in the next request then modifies the
same data using a 3rd protocol in the request after that. 

The usual reaction from unix developers when they hear this is "well
don't use that windows crap then". The problem is that the point of
Samba is to allow people to use windows if they want to. We are
delighted to hear about people who have migrated their clients away
from Windows, but for those that haven't we try to provide a solution
that is as painless as possible.

It certainly would be less work for us as developers to just say 'use
openldap, use MIT or heimdal kerberos, use freedce'. Luke demonstrated
that the approach does work when he wrote XAD. If our aim was to
minimise developer time then that approach would quite possibly be the
correct one, but that isn't our aim. Our aim is to reduce the time and
effort required to deploy Samba for the vast majority of users who
don't have any of these services currently installed.

That doesn't mean we shouldn't be able to use existing services if
they exist. When I wrote ldb I also wrote a ldap backend for it, so
you can use ldb with an existing ldap database. So for those people
who just want ADS and don't care about having a standards compliant
ldap server they can use ldb with its tdb backend, and they don't have
to go through any pain in configuring it (with the tdb backend an
empty file is a valid database, ready to use). For those people who
have gone to the effort of setting up a good ldap infrastructure they
will be able to change one line in the Samba config and they can point
smbd at their existing ldap server. Then we just need some way to
match the schema, but that is a problem no matter what ldap server we
use, as the schema is mandated by the fact that you are using Windows
ADS clients.

It would be fantastic if we could do the same for kerberos. Having a
really simple kdc builtin would be a huge advantage for the majority
of users who have no kerberos infrastructure at the moment and don't
care at all about the fact that ADS uses kerberos. If we could
trivially point Samba at an existing KDC and still implement all the
bits we need to interoperate with Windows then that would be great.

Cheers, Tridge