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: http://lists.samba.org/archive/samba-technical/2005-May/040869.html > (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... :-) Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
This is a digitally signed message part