Current ideas on kerberos requirements for Samba4
abartlet at samba.org
Tue May 24 05:56:33 EDT 2005
On Mon, 2005-05-23 at 22:41 -0400, Jeffrey Hutzelman wrote:
> "What he said". Seriously, I have strong reservations about such an
> approach from three standpoints:
"What tridge said". But again on a serious point, I think tridge's post
may have missed some of you not on samba-technical, because the other
lists are subscriber posting only:
> (1) From the point of view of a software engineer and protocol designer:
> Kerberos is not part of your (or any) application; it is a core
> infrastructure service which must be shared among many applications.
Perhaps I didn't make this point clear when I started this discussion,
but there seems to be a little confusion as to why Samba is suddenly
interested in the KDC space.
Samba4 is an project with a very big goal - to provide a Free Software
implementation of the CIFS/SMB protocol, and all the other protocols
required in order to make it work with modern clients. This has
extended to those protocols used by Active Directory.
It is only in trying to meet the need for an 'AD-like' Kerberos service,
as required by Microsoft's clients, that we even enter this space. It
is not Samba-as-a-file-server that moved us in that direction.
> Good design requires a certain amount of modularity, with separate
> tasks being performed by separate components communicating through
> well-defined interfaces. This allows each component to be managed
> separately, and ensures that they will all interoperate.
> Including the KDC in Samba will likely result in the two becoming
> tightly coupled. It will make it easier for smbd to violate all
> sorts of abstractions and to depend on private interfaces which make
> it fail to interoperate with standard KDC's. If multiple applications
> had such a requirement, they would be unable to coexist in the same
> environment, because while a given Kerberos realm may support many
> applications, it can have only one set of KDC's.
This is the situation we are in currently, the Microsoft clients expect
a very tight interface between the KDC and the rest of the domain
controller (requiring coherent operations over multiple protocols, the
PAC and other fun things).
However, we also have a very different modal, where we are a domain
member, and in this modal we are much more relaxed as to what the KDC
is, and we will try and work with anybodies KDC. The issues of managing
domains and trying to get Windows clients to accept our tickets will no
longer haunt us, and we can get on with life.
To make it clear, Samba4 as a member (non-DC) will have *no* special KDC
requirements, and I hope will be an even better Kerberos client citizen
than Samba3 is.
> (2) From the point of view of a Kerberos administrator:
> As for Ken, that would be a total non-starter for me, due to both
> security and maintainability considerations. I'm uninterested in
> incorporating into my KDC's a large pile of code which has nothing
> at all to do with Kerberos and serves only as a source of potential
> vulnerabilities. I'm much more likely to run (or even port, if
> necessary) a small, easily-analyzed plugin which provides only those
> specialized Kerberos-related functions required by the application.
I suspect you would have no role for Samba4 leading an Active Directory
style domain, and nor would you wish the NTLM password algorithm
anywhere near your password database.
But I won't shut off the interfaces required to design such a plugin,
however I can assure you it will not be small. (Particularly if you
consider the whole Samba4 suite that is required to be at the same IP).
> (3) From the point of view of someone who's faced similar issues before:
> The primary purpose of OpenAFS is to provide a scalable, cross-platform
> distributed filesystem.
> We want people to run a real KDC. We've been in the business of
> supporting a KDC unique to our filesystem application, and we didn't
> like it one bit. Just a friendly word of advice...
I appreciate the advise. I think our situation is different, but I'll
no doubt look back in a few years and wonder what might have been... :-)
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/19bb9506/attachment.bin
More information about the krbdev