Current ideas on kerberos requirements for Samba4
abartlet at samba.org
Mon May 23 20:06:44 EDT 2005
On Mon, 2005-05-23 at 14:50 -0400, Sam Hartman wrote:
> Andrew and I had this conversation on IRC, but I feel the need to
> state the following publically for the record.
And I'm glad to finally get a discussion going here, lest it be said
that we did our kerberos work in the shadows and the dark :-).
> I think that Samba including a KDC based either on Heimdal or MIT is a
> non-starter for several OS vendors. They need to be able to treat
> Samba as one Kerberos service that provides authorization, group
> membership, etc. However Samba will not be the only such service.
> The OS vendors also have a strong requirement to have a single
> Kerberos implementation.
> That said, Samba needs to have a solution for users who are not OS
> vendors. Also, it seems reasonable that Samba does not want to do the
> OS vendors work for them.
Indeed, I'm not going to 'do the OS vendors work for them', as I have
enough work to do getting this ship sailing at all, let along dealing
with the particular requirements of unnamed 'vendors'. But I'm also at
a bit of a loss: aside from some desire 'not to ship more than one KDC',
I'm yet to hear what they feel 'they' need (or who these vendors are).
It would be great if they could join in the discussion on samba-
technical. Perhaps their requirements are more easily addressed than I
I would also like to see how this compares or contrasts with a desire to
'only ship one LDAP server', where we do hit a similar issue. This is
something where we have had recent discussion.
> I do believe that linking the kdc into the smbd process really does
> create an untenible situation for a lot of people and I think you will
> find that the work required to get access to Samba facilities in a
> native KDC is well worth the effort in the long run.
I honestly don't see what we (or indeed an OS vendor) gains using a
'native' KDC (whatever that means). Can you outline that in something
But I do by linking inside smbd (or other very close tying) we get to
- network interfaces
all inside Samba itself. This is perhaps the most tempting part -
knowing that the administrator cannot 'forget to start the kdc', or
'forget the magic lines in the /etc/krb5.conf'. This makes our KDC fit
quite well with the overall design of Samba4 (one smbd to rule them
Also, by linking them closely, we can transparently access the same
routines for access control, PAC generation, string manipulation and the
like. (Without trying to define static/shared library interfaces for
all of this, for the special case of the KDC only)
Finally, if we ship our own KDC, we know what is on the other side of
the interface. Vendor-supplied Kerberos libraries have been a nightmare
for us over the life of Samba3, I can't imagine what dealing with
plugins for an arbitrary vendor-supplied KDC would be like.
> I do think it is reasonable and necessary at the current time for
> Samba to include a KDC of some kind; I agree that Heimdal is the least
> effort for Samba at the current time.
> I think it is also important to work with OS vendors in this. I think
> you need to design Samba assuming that people will end up supplying
> patches to plug Samba into the system KDC. (Yes, I fully realize that
> Samba will get involved in almost all aspects of handling a request).
> I think it will be important to try and work with those vendors to
> integrate their patches when such patches are written.
This all said, I am willing to work with anybody who can provide sane
patches, and can argue why they are a long-term viable proposition to
I am not tied permanently to this direction, and good software
engineering arguments (preferably backed with patches) or unexpected
research results may certainly change my view.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20050524/375f4d3e/attachment.bin
More information about the krbdev