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 fear. 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 more concrete? But I do by linking inside smbd (or other very close tying) we get to control: - Startup/shutdown - network interfaces - configuration 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 all...) 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 the project. 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 -- 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