On Tue, 2005-05-17 at 01:36 +1000, Andrew Bartlett wrote:
> Just a quick note to let a few more people know that I am putting > together a rough text document describing various things about kerberos. > I'm sure parts are just complete fiction, but I'm still new to many > parts of this game. :-) > > The idea is to write down the special things Samba4 will need from > GSSAPI/Kerberos libraries and KDC implementations, however we end up > producing things. So, things have progressed a lot over the last week, and I want to fill in the various concerned lists as to my current status, and the research direction. KDC --- The research direction so far shows that Samba4 can use Heimdal kerberos for it's KDC needs: the only major remaining issue is the PAC generation, and I know this is at least possible. We are currently looking at how we will start and plug into the KDC, and I'm wondering if we can do so by linking the KDC code directly into the main smbd process, just like our other services. Linking directly 'in process' has a number of advantages, particularly because I can then use many of the other facilities of Samba4 behind the heimdal interfaces. For example I can use our UTF8 manipulation code, our full db layer (including ACLs as required for the password change deamon), and not rely on getting all these bits into shared/static libraries. My current feeling is that Samba may well ship it's own KDC (based either on Heimdal, our own code or potentially some other codebase) for some time into the future. To whatever extent Samba includes a derivative of another distribution of kerberos, the aim would be to keep the 'diff' between the two projects as small as possible, while integrating the code for minimum administrative and engineering pain. At an engineering level, this might entail a libkdc.a supplied either with Samba, or perhaps at some long-future date, supplied by the operating system. Client Libs ----------- A more open question surrounds the client libraries - Samba has very particular needs for a 'state machine safe', 'asynchronous' and (to a lesser extent) thread safe GSSAPI layer. I'm still looking at what pain it will take to modify Heimdal (mostly looking at the gssapi_krb5_context) to meet these requirements. I also need to look at GNU GSS and the MIT libs here. I intend to write some tests to show the safety or otherwise of these libs, by constructing and using parallel contexts. In the short-term, my current research indicates that it should be viable for Samba4 to ship a modified snapshot of Heimdal's GSSAPI/Kerberos library, and use that library if the system libs are not found suitable. Indeed, my hope is that in the long-term, we will not need to maintain these in Samba, and we will be able to use whichever brand of system kerberos lib is available. How this interacts with KDC design will be another important point to watch. > The current version (updated from SVN) is at: > http://samba.org/ftp/unpacked/samba4/source/auth/kerberos/kerberos- > notes.txt I hope to keep this updated, as I make things more concrete. In any case, this mail is a request for discussion - I want know if I'm mad, and if so, what other solutions/suggestions do you have? I do realise that the idea of a 'Samba KDC' still makes a number of people uncomfortable, but I'm also at a loss to find software engineering reasons to propose any other forward direction. That is why I'm writing this mail. BTW, I also look forward to the public release of the code behind http://web.mit.edu/jaltman/Public/Samba-XP-Presentation.pdf to see how it compares/complements/contrasts with our current approach. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
>My current feeling is that Samba may well ship it's own KDC (based
>either on Heimdal, our own code or potentially some other codebase) for >some time into the future. To whatever extent Samba includes a >derivative of another distribution of kerberos, the aim would be to keep >the 'diff' between the two projects as small as possible, while >integrating the code for minimum administrative and engineering pain. Just my $0.02: I already have a hacked KDC (based on MIT) that has a number of custom extensions that I need. Running a Samba-supplied KDC is simply a non-starter. I know plenty of people who are in the same boat. Just as an aside - it seems when you do Kerberos for a while, you find that you need to do some number of changes to make it fit better at your site, so this sort of thing just tends to crop up. This probably isn't an issue for smaller sites, or sites that just want to run a KDC to suppot Samba. If you provide a chunk of code and say, "You need to integrate this", then that's fine with me (if it's Heimdal-only, then that will be a pain, but I can deal). I know, I could always do cross-realm ... but trust me, I have more experience with cross-realm than most people, and I'm not going to run a seperate realm just for Samba. --Ken _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
Andrew and I had this conversation on IRC, but I feel the need to
state the following publically for the record. 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. 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 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. --Sam _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
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. 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. 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 _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Ken Hornstein
On Mon, 2005-05-23 at 11:18 -0400, Ken Hornstein wrote:
> >My current feeling is that Samba may well ship it's own KDC (based > >either on Heimdal, our own code or potentially some other codebase) for > >some time into the future. To whatever extent Samba includes a > >derivative of another distribution of kerberos, the aim would be to keep > >the 'diff' between the two projects as small as possible, while > >integrating the code for minimum administrative and engineering pain. > > Just my $0.02: > > I already have a hacked KDC (based on MIT) that has a number of custom > extensions that I need. Running a Samba-supplied KDC is simply a > non-starter. I know plenty of people who are in the same boat. Just > as an aside - it seems when you do Kerberos for a while, you find that > you need to do some number of changes to make it fit better at your > site, so this sort of thing just tends to crop up. This probably > isn't an issue for smaller sites, or sites that just want to run a KDC > to suppot Samba. Samba4's LDAP server is not intended to be a world-class (or even standards-conforming) LDAP server, I'm targeting our KDC as a match for the Microsoft interface, not as the new gold standard for KDCs in POSIX. I'm trying to fill the space currently filled by Microsoft's Active Directory, not trying (particularly in the first release of Samba4) to replace an existing corporate Kerberos infrastructure. Now, I come at this whole area from rather a different direction than I suspect you do, because I'm not steeped in the history of Kerberos, nor do I run a large and complex site that uses it. What is custom about your kerberos setup, and given that I realise that having multiple kerberos realms is the pits, what could we do to make your life easier? > If you provide a chunk of code and say, "You need to integrate this", > then that's fine with me (if it's Heimdal-only, then that will be a > pain, but I can deal). I know, I could always do cross-realm ... but > trust me, I have more experience with cross-realm than most people, and > I'm not going to run a seperate realm just for Samba. Well, it will always be open source, so unlike AD you can hack it however you please :-) My observation is that sites fit into one of the these three boxes: (98%) Never used Kerberos, or don't know what Kerberos is: - NT4 sites - Samba3 based sites - Low-clue AD networks (you don't need to understand Kerberos to use AD) - Everybody else (most linux networks, workgroups) (~1.75%) Large sites, which run AD, know what kerberos is and use it to their advantage (<.25%) Sites that chose to use unix-based kerberos systems, and have integrated it properly into a majority of their systems. My problem is that while I do *not* wish to exclude anybody, I need to care about the first two categories far more than the clued-in SysAdmin of a real kerberos site. (Where I think that long-term, we can work something out). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
Andrew Bartlett wrote:
> On Mon, 2005-05-23 at 14:50 -0400, Sam Hartman wrote: >>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). The most fundamental principle of working in the Unix programming environment is to create efficient single-purpose tools that play well with other tools. The desire "not to ship more than one KDC" is not just a petty foible, it's a key to efficiently deploying whatever limited resources you have. Nobody wants to be wasting resources maintaining two separate items with overlapping function. And strange as it may seem, there will be plenty of sites out there that want a KDC but don't want or need an SMB service. Moreover, there are plenty of sites out there that already have a KDC that works for them. It would be a waste of their resources to have to learn how to use/administer yours. As Ken said, it would probably be more effort than any sysadmin is willing to invest, to set up a cross-realm trust with yours, when there should only be one realm in the first place. And they may be stuck with something (like a DCE installation) where they already have an irreplaceable KDC, and don't want to go through that heartburn again. (Of course, a site running DCE won't play well with Samba4 anyway, since it will have its own rpc listener.) Indeed, one should take a good hard look at DCE (and MS AD) and learn from them, not make the same stupid mistakes over and over. It is certainly important that your services are so well integrated that using them is seamless. But it is also important that your services' boundaries are so well defined that you can remove one component and replace it with another one, at will. > 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. Yes... And as LDAP is a major piece of core infrastructure, it's another example of "I have one working already, don't make me use another one." People thought that meta-directories would be the solution to the directory proliferation problem, but experience has shown that they just turn the N-directory management problem into N+1. With that said, I'm less worried about LDAP because there are valid reasons for keeping a security management directory isolated from a general whitepages directory, even if that creates redundant, overlapping directory namespaces. > 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...) Like I said, seamless operation is an admirable goal, but crossing component boundaries and breaking abstraction layers is a mistake. The biggest problem with asserting all the control you want here is that Samba is not the only consumer of Kerberos service in a network. Also, the simple reality of software complexity dictates that an integrated KDC+SMB server will crash more frequently than separate standalone KDC and SMB servers. It is inappropriate to deny Kerberos service to the network due to an SMB failure. > 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 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. Good software engineering practice dictates that when you have problems working with someone's interface, the solution is to fix the interface, not replace their backend with your own. I'm rather surprised that even needs to be said, but apparently it does. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Ken Hornstein
On Monday, May 23, 2005 11:18:00 AM -0400 Ken Hornstein <[hidden email]> wrote: >> My current feeling is that Samba may well ship it's own KDC (based >> either on Heimdal, our own code or potentially some other codebase) for >> some time into the future. To whatever extent Samba includes a >> derivative of another distribution of kerberos, the aim would be to keep >> the 'diff' between the two projects as small as possible, while >> integrating the code for minimum administrative and engineering pain. > > Just my $0.02: > > I already have a hacked KDC (based on MIT) that has a number of custom > extensions that I need. Running a Samba-supplied KDC is simply a > non-starter. I know plenty of people who are in the same boat. Just > as an aside - it seems when you do Kerberos for a while, you find that > you need to do some number of changes to make it fit better at your > site, so this sort of thing just tends to crop up. This probably > isn't an issue for smaller sites, or sites that just want to run a KDC > to suppot Samba. > > If you provide a chunk of code and say, "You need to integrate this", > then that's fine with me (if it's Heimdal-only, then that will be a > pain, but I can deal). I know, I could always do cross-realm ... but > trust me, I have more experience with cross-realm than most people, and > I'm not going to run a seperate realm just for Samba "What he said". Seriously, I have strong reservations about such an approach from three standpoints: (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. 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. (2) From the point of view of a Kerberos administrator: Like Ken, I run Kerberos and other infrastructure for a site with fairly complex requirements. Like Ken, my KDC's run modified software with a number of local extensions (not the same ones). My KDC's are carefully managed and tightly secured. They run on dedicated, locked-down machines in locked cabinets in locked rooms with video surveillance and direct-to-paper logging. Both network and physical access to the machines is tightly controlled, and only about 5 people have the ability to log in to them. The KDC software is based on a distribution signed by someone personally known to me, and most of the other code has been carefully analyzed as well. I'll admit that most sites probably aren't quite as paranoid as we are, and certainly most don't chat with their KDC vendor on a daily basis. But a good number of people are that paranoid, or more, and even those who don't have custom KDC modifications are unlikely to want to run some application-specific KDC with unknown properties. 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. (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. Unfortunately, the OpenAFS distribution has traditionally included quite a number of tools which are not related to this purpose. Among other things it includes an FTP server, inetd, login, an NTP server, rlogin/rsh, a software maintenance tool (package), and yes, an authentication service. All of these components are old, poorly maintained, and have been obsoleted newer, better software available elsewhere. Some of them are downright dangerous, and building them requires the use of a special configure switch (--enable-insecure). What's worse, most of these packages have _always_ been this way, since day one. This stuff was in the Transarc distributions over a decade ago, and it was obsolete and insecure back then, too. We recently decided to remove nearly all of these independent packages from the OpenAFS tree, and concentrate more fully on our core purpose. Of the components I mentioned above, the only ones we haven't thrown away are package (which probably should be) and the kaserver, which we've kept around only because there are a few sites out there who still depend on it. Note that anytime someone comes to us with a question of the form "we're running the kaserver and...", the answer is "don't do that; go get a real KDC". 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... -- Jeff _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by hartmans
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 _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Jeffrey Hutzelman
I can only echo what everyone else has said, and also mention that not
everyone who does Kerberos does cross-realm. There have been security vulerabilities in the past, fixed now of course, that *only* affected cross-realm, so sites that never needed it had good reasons not to run it. And frankly, still do, since after all the best way to avoid potential vulerabilities in code is to not run it in the first place when it's not needed. That being said, I do understand where you're coming from and why you would need to tie into a KDC pretty intimately to accomplish what you're trying to do. However, the more independent you can keep that from the rest of your application, I think the happier you will be in the long run. The ideal case is if the minimum necessary KDC hooks could somehow be determined and modularized and then integrated into an existing KDC (Heimdal if that's the easiest) with the possibility that other KDC implementations could pick them up. That way, the KDCs could continue to do the KDC thing and you could just use the results. Jeffrey Hutzelman <[hidden email]> writes: > We recently decided to remove nearly all of these independent > packages from the OpenAFS tree, and concentrate more fully on our > core purpose. Of the components I mentioned above, the only ones we > haven't thrown away are package (which probably should be) and the > kaserver, which we've kept around only because there are a few sites > out there who still depend on it. Note that anytime someone comes > to us with a question of the form "we're running the kaserver > and...", the answer is "don't do that; go get a real KDC". > 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... And just think what the world would look like today if AFS had never contained a KDC and had always asked people to run an external one. The linkages wouldn't be as tight as they ended up being, I expect the migration to K5 would have been easier because of that, the AFS KDC wouldn't have ended up being a unique implementation with quirks that differed from any other KDC, and the whole system would likely be more modular and more robust at this point. (On the other hand, we might not have had Ubik for the KDC, which would have been a shame... but on the gripping hand, maybe that would have sparked more work on separating Ubik from AFS so that other protocols could have been using it.) -- Russ Allbery ([hidden email]) <http://www.eyrie.org/~eagle/> _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
On Tue, May 24, 2005 at 10:06:44AM +1000, Andrew Bartlett wrote:
> 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'm by no means even a Kerberos novice and I haven't been following the Samba4 code very closely, but maybe I can contribute some vendor perspective. These are personal opinions and do not necessarily reflect the official views or plans of SGI. o Customers want a unified Kerberos infrastructure today. It would be good if Samba4 brought us a step further to being able to seamlessly use Kerberos for CIFS, NFS and local logins. o Many vendors are already shipping multiple versions of Kerberos and other crypto libraries for various reasons (not all of them good). Each time this happens, there is a cost involved in code maintenance, issuing security updates and patches, interop, diagnosing customer problems, etc. o The desire not to ship more that one KDC is pretty strong. I would think that vendors supporting Heimdall and MIT KDCs feel they already get enough support calls without a Samba KDC. o Convincing customers to upgrade is (justifiably) hard. If I need to upgrade Samba, will the customer be willing to risk the corresponding KDC upgrade? If not, will I have to spin a site-specific patch? o Finally, my guess is that vendors will eventually ship Samba4 whatever happens because there will be customer demand. -- James Peach | [hidden email] | SGI Australian Software Group I don't speak for SGI. _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
On Tue, 2005-05-24 at 18:23 +1000, James Peach wrote:
> On Tue, May 24, 2005 at 10:06:44AM +1000, Andrew Bartlett wrote: > > 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'm by no means even a Kerberos novice and I haven't been following the > Samba4 code very closely, but maybe I can contribute some vendor > perspective. These are personal opinions and do not necessarily reflect > the official views or plans of SGI. > > o Customers want a unified Kerberos infrastructure today. It would > be good if Samba4 brought us a step further to being able to > seamlessly use Kerberos for CIFS, NFS and local logins. thrown at them, where they are just another kerberised service (just accepting file shares). What makes Samba4 different is that it is trying to be compatible with Microsoft's Active Directory, so we have sudden demand to 'provide' a KDC, because that's what our clients expect (and they expect particular behaviours). > o Many vendors are already shipping multiple versions of Kerberos > and other crypto libraries for various reasons (not all of them > good). Each time this happens, there is a cost involved in code > maintenance, issuing security updates and patches, interop, > diagnosing customer problems, etc. > > o The desire not to ship more that one KDC is pretty strong. I would > think that vendors supporting Heimdall and MIT KDCs feel they > already get enough support calls without a Samba KDC. Is there a support call cost difference between a MIT or Heimdal KDC with most facets of their operation influenced by a Samba module, and a KDC built in and 'just working' inside Samba? My argument is that where Samba controls such a KDC from a logic perspective, it is already a 'different KDC'. > o Convincing customers to upgrade is (justifiably) hard. If I need > to upgrade Samba, will the customer be willing to risk the > corresponding KDC upgrade? If not, will I have to spin a > site-specific patch? Samba4 will be a big change, but if you already have a KDC you are quite happy with, you probably don't want to turn Samba4 on as a DC of any sort anyway. The fileserver will certainly not require it's own KDC. > o Finally, my guess is that vendors will eventually ship Samba4 > whatever happens because there will be customer demand. I think you are right on this one :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Jeffrey Hutzelman
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. 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 _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
Andrew Tridgell wrote:
> 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 fact that you or some LUG presenter struggled with the process doesn't mean that the process is broken or untenable. In the case of whatever LUG talk you were at, they clearly hired the wrong speaker. I can bring up a Heimdal KDC and OpenLDAP server playing together within one minute from typing "make install". Of course, with Symas' prepackaged OpenLDAP and Heimdal binaries, anyone can do it in a few seconds after installing the depots/pkgs/RPMs/etc. There are a lot of self-proclaimed LDAP experts out in the world making money on their false claims, but their failure to produce results is no indication of the true nature of the situation. There are a lot of bogus HOWTOs out there claiming to give authoritative advice on setting up Kerberos and OpenLDAP, but their authors are not active members of the Kerberos or OpenLDAP software communities, and these authors obviously have no idea what they're talking about. Being a long-time active member of the Heimdal, Cyrus, OpenLDAP, and OpenSSL communities, I must say I have never seen a question from you on any of these lists regarding how to make OpenLDAP play with any particular secure authentication mechanism, so I have to wonder where you've been going for "expert" advice on the topics. It seems you've gone to the wrong places thus far. When you work in isolation from the community that develops this software, and complain of extraordinarily painful experiences, I think you bring it on yourself. I find it rather difficult to understand how someone who leads an open source project as you do can have missed tapping into the abundant resources that open source development provides. Andrew Bartlett made a similar comment to your "mainstream Linux variant"; it's common knowledge in the OpenLDAP community that major distros like RedHat have been shipping extremely outdated OpenLDAP releases. If you had simply checked the OpenLDAP web site, or the mailing lists, it would have taken you no time at all to realize that you were working with something obsoleted in 2002 and probably ought to get something newer that worked reasonably. It may be obnoxious to belabor the point, but it's something that has puzzled me for quite some time; why does it take so long for people using a software package to go back to the package's community for help when they run into trouble? The READMEs, the INSTALL notes, everything is plastered with URLs of where to find more information or ask questions. And yet I still see people asking questions in obscure corners of cyberspace, where there's little chance that anyone with an answer will ever see the question. Speaking as someone who first started working with Kerberos and AFS back at UMich more than 15 years ago, I can tell you that "Having a really simple KDC built in" would be a good way to invite security breaches into a network. You might as well use eBones. When people who don't understand security and encryption technology start rolling their own, it's a recipe for disaster. (Just look at the fool who decided it was a good idea to use the Unix crypt password as part of the AFS string2key function. They only used the first 8 bytes of the crypt string, which itself is a 13 character 6-bit-per-character encoding of a 56 bit DES key. And the first two characters are just a salt. End result, the AFS keys only have 36 bits of entropy, even though they thought they were doing 56 bit DES. 15 years ago 56 bit DES was impractical to crack, but 36 bits? Anyone with an idle workstation could do it.) The goals you've outlined for Samba4 are admirable. But worrying avout losing your userbase should be secondary to worrying about getting the job done right. If it takes a little longer to get it right, your userbase will still come around in the end. If you muck it up at the beginning and some high profile user's network gets compromised, you will lose your userbase forever. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Andrew Bartlett wrote: | Perhaps we should make something clear from the | outset. Just as Samba4's LDAP server is not | intended to be a world-class (or even standards-conforming) | LDAP server, Andrew, I'm not getting into this thread for obvious reasons, but I think this is a very dangerous statement (and assumption) to make. You are claiming to match against AD. That's a big order from the LDAP side of things. People will expect you to get the LDAP part right if you are taking it over. | I'm targeting our KDC as a match for the Microsoft | interface, not as the new gold standard for KDCs in POSIX. Again, I think this is a dangerous assumption to make. . | I'm trying to fill the space currently filled | by Microsoft's Active Directory, not trying | (particularly in the first release of Samba4) to | replace an existing corporate Kerberos infrastructure. But in a way you are and I think that is the concern that is expressed. This is a tough road. I think there are two basic philosophies at work here. One is to use Samba as a bridge between Windows and Unix. Here Samba is a thin layer of glue. We have posix mappings of ACLs, lpr print queues exported to clients, and posixAccounts integrated with Samba accounts. The other side of the fence is to reimplement AD. A very admirable goal. But to be 100%, you are not longer acting as a thin layer of glue. In some ways, Samba no longer acts as an interoperability tool. It the network portion of the OS. At this point the justification to install Samba is not based on interoperability because Samba is acting just like AD. Not solving existing interoperability issues between Unix and AD. The justification of installing Samba is based on license fees. If you want to add interoperability back to the buffet, then the Samba4 kdc implementation (and LDAP implementation) will have to be world class, scalable implementations. I think you might also be ignoring the fact that while CIFS is primarily a Windows protocol, LDAP and Kerberos will be used by non-MS clients and so at some point you will have to support them as well. cheers, jerry ===================================================================== Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "I never saved anything for the swim back." Ethan Hawk in Gattaca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkyeMIR7qMdg1EfYRAr5GAKDi82AkLYaTnoNZvFQJC6hVUn3fqACgxqOF GVuaXnptF81Yy9yYXF+JfCY= =hQpk -----END PGP SIGNATURE----- _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Howard Chu
Howard,
The type of users we are aiming at are not the ones who read documentation on ancillary packages. We have trouble enough getting our users to read the Samba docs, let alone reading the docs on half a dozen external services they would need to install to make Samba4 work. For the types of end users we are aiming for, setting up a kerberos realm is like asking them to setup /etc/memcpy.conf. The fact that we call memcpy() in Samba is completely irrelevant to what our users are trying to achieve, which is to install a file server for their windows clients. They don't care that we use memcpy(), and they don't care that recent versions of windows now send auth packets formatted according to krb5 standards. I think that Samba3 is far to hard too install and configure. I want to make Samba4 much easier, and my fear is that it will in fact become much harder as we start to become dependent on more external tools. Ideally krb5 and ldap would be like our lib/popt/ code. We detect if the system has a working popt library, and if it does then we use it. If it doesn't then we use the version we ship with the code. That is the idea of ldb with the ldap backend. It means people who don't care about the fact that their network now has an ldap server can use the builtin ldb code. For those who do care, they can tell Samba to use an existing ldap server. The default will be to use the builtin one, as the defaults are meant for the majority who don't know about the intricacies of ldap. If we can achieve that with krb5 as well then that would be great. Andrew Bartlett has been working with lha to try to achieve that with Heimdal for quite a while. They have made a lot of progress, but we still don't have anything we can usefully ship, although its getting close. We are not trying to replace the roles that MIT and Heimdal kerberos have played over the years. If someone wants a KDC, they should certainly install a real one, and not use Samba as their KDC. What we want is something that is invisible for people who want to remain blissfully unaware of the fact that krb5 packets are flying over their network. They want the Windows admin tools to work and that is it. One way of looking at this is that we are trying to protect the MIT and Heimdal communities from the hordes of Samba users asking you silly questions when Samba4 comes out :-) Cheers, Tridge _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
Andrew Tridgell wrote:
> Howard, > > The type of users we are aiming at are not the ones who read > documentation on ancillary packages. We have trouble enough getting > our users to read the Samba docs, let alone reading the docs on half a > dozen external services they would need to install to make Samba4 > work. > For the types of end users we are aiming for, setting up a kerberos > realm is like asking them to setup /etc/memcpy.conf. The fact that we > call memcpy() in Samba is completely irrelevant to what our users are > trying to achieve, which is to install a file server for their windows > clients. They don't care that we use memcpy(), and they don't care > that recent versions of windows now send auth packets formatted > according to krb5 standards. We seem to have a basic philosophical disagreement here. I'll make one more response in that regard and then let it drop. Yes, it is a Good Thing to make software easier to use. But (IMO) it is Not a Good Thing to cater to user ignorance. This is what the American entertainment industry has been doing for decades. Yes, it makes that industry a tidy profit year after year, and it also encourages more and more people to turn off their brains. As the developer of a piece of software that is extremely popular and widely deployed, you are in a unique position to influence the world, for good or ill. You can aim for the low engagement user, and drag the rest of the world down to their level, or you can aim for a higher grade, and encourage the world to come up to your standard. (Besides, aiming to make software that even idiots can use is always a losing proposition - as the saying goes, you can't make anything idiot-proof because Nature will just make a better idiot.) The issue is particularly critical here, because you're talking about integrating a piece of security infrastructure. Security and ignorance cannot coexist. Sure, people don't have to understand the 3-way handshakes and all the encryption layers to be productive, but they do have to understand the basic notions of Trust as it relates to principals and realms. Nobody is going to just drop it in and turn it on and go merrily on their way. Not even Windows administrators. > I think that Samba3 is far to hard too install and configure. I want > to make Samba4 much easier, and my fear is that it will in fact become > much harder as we start to become dependent on more external tools. You can create a nicely integrated package from multiple components without needing to reimplement all of the components. Symas has done it with our CDS packages (OpenLDAP+BerkeleyDB+Cyrus SASL+Heimdal+OpenSSL), and PADL has done it with XAD. You get far more mileage out of your own time and resources by leveraging what already exists. When you run into rough edges, you beat them into submission and move on... ;) > One way of looking at this is that we are trying to protect the MIT > and Heimdal communities from the hordes of Samba users asking you > silly questions when Samba4 comes out :-) Some times, hordes of annoying questions can be a good motivator for projects to improve their docs and/or ease-of-use. It certainly exposes weak spots... -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
>Now, I come at this whole area from rather a different direction than I
>suspect you do, because I'm not steeped in the history of Kerberos, nor >do I run a large and complex site that uses it. What is custom about >your kerberos setup, and given that I realise that having multiple >kerberos realms is the pits, what could we do to make your life easier? In terms of our Kerberos KDC ... we have the following customizations (these are the ones I remember off-hand): - Support for hardware preauthentication - Special code to disable _some_ users if they don't kinit with the right enctypes - Extended logging - A weirdo protocol to support the use of a hardware token combined with the local host key (we have a special version of sudo that uses that). - Special enctype selection code (to deal with breakage from older clients, but I suppose we don't need that anymore). Those are just the ones I remember right now; there are probably others. Oh, and you _do_ support IPv6, right? :-) Note that none of these change the core protocol (well, hardware preauth does, but while that protocol hasn't gone through the whole IETF process yet, let's pretend it's standardized). I think I've got more changes to the Kerberos codebase than most people (well, except maybe for those losers at Stanford :-) ), but I try to adhere to some rules. First, no changes to the core protocol. No changes to existing APIs (except maybe the adding of flags, if the function takes flags). Adding new API functions is okay, but I try to avoid it if possible. Changes to the KDC behavior (e.g., what enctypes the KDC decides to use) are fine. Changes to application servers are okay, but I prefer changing the KDC. Changes to the clients are to be avoided unless there is no other way to accomplish what I need to do. I guess the best thing to do would be to explain what I (as a site) need to add in terms of functionality to the KDC. If I need to generate PAC information (for example), then that's one thing. If you have code to get out the group membership from your LDAP server (and if it worked with MIT Kerberos), hey, even better :-) >My observation is that sites fit into one of the these three boxes: >[...] I could believe your numbers, if we're talking about _sites_. However, if we throw number of users in the mix, I suspect the numbers will be different (my experience is that some larger sites want more integration and have already figured out Kerberos already). But, for the sake of this discussion, let's take your numbers as correct (they're probably not far off). >My problem is that while I do *not* wish to exclude anybody, I need to >care about the first two categories far more than the clued-in SysAdmin >of a real kerberos site. (Where I think that long-term, we can work >something out). Hey, I understand your pain. I mean, I basically spent a YEAR messing around with Kerberos before I understood it well enough to deal with deploying it at our site (at the end of that year, I understood it all the way from the protocol level down to the APIs, and had probably seen every Kerberos error message under the sun). Is it reasonable to ask your typical guy who wants to run Samba to do that? Hell no! I think given your requirements, shipping a _basic_ KDC is probably unavoidable. I just wanted to point out that there is a number of us who really want to use our own KDCs with Samba4, and we'd like you to be able to deal with that at some point. I don't think there's a huge amount of work you have to do to make that happen (at least, I hope not). --Ken _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
On Tue, 24 May 2005 19:56:33 +1000
Andrew Bartlett <[hidden email]> wrote: > 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). I'm no expert on anything, but that's not going to stop me :-> Personally, I'm quite wary of seeing new KDC/LDAP implementations. We already have good ones out there under active development, and I'd like to see them used in the project instead of yet more code duplication. I don't know the intimate details of what AD clients expect from an AD controller, but I wonder if perhaps the requirements could be addressed by a meta-smbd of sorts? The meta-smbd acts as an AD controller, but passes off requests for various services to the respective daemons, something like this: XP -- TGT/PAC req --> -- AS_REQ --> Heimdal/MIT KDC <-- TGT -- meta-smbd <-- TGT/PAC -- Group LDAP req --> OpenLDAP (genPAC) <-- groups That's just one example. I don't know how feasible it is, but I just thought I'd throw the idea out. Since one of the motivating factors for the integration of services is the difficulty experienced when trying to integrate the various packages to work together, perhaps this should be the area of focus for an AD controller clone: scripts/configuration systems that make it easy to combine all the various packages out there (Heimdal/SASL/OpenLDAP/etc) to work together in a conherent way to form the basis for a production-level AD controller. I know how hard it can be having done it myself, but I don't know if that's a good reason to try to re-implement functions that are already available in stable, actively-maintained packages. Focusing on easing the integration seems a better route IMO. ---------------------------------------------------------------------- | Jim Hranicky, Senior SysAdmin UF/CISE Department | | E314D CSE Building Phone (352) 392-1499 | | [hidden email] http://www.cise.ufl.edu/~jfh | ---------------------------------------------------------------------- _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Andrew Bartlett
So far all the respondents to this thread represent the 2% of the sites
and have all be active with Kerberos and AFS for years, but do understand the issues of the other 98%. You have suggested a libkdc, and shipping someone else KDC. What about the other way around, where you work with the KDC vendors, to add the hooks needed to support your needs. In this way you could work your way gradually into an existing Kerberos environment, and could also ship or point at the KDC vendors to use. It really comes down to what are the real requirements for the KDC and what are the minimal changes required. It would appear that the first thing needed is to add a PAC to a Kerberos ticket for a samba server, or even to a TGT. From a first glance, a KDC could make a simple call out to your libs to do this. Also to start with, you may want to consider letting the KDC use its own databases for its authentication information separate from the authorization information you need for the PAC. This would also make is much simpler on the KDC or existing sites. I would really like to see them separate. Your AD replacement could use the kadmin interfaces to update the KDC's databases much like the kadmind does today if really needed. This is only a first cut, but I would suspect that the authentication and AD like authorization could be separated out keeping the KDC and the AD functions pretty much separate. I am sure the the Kerberos vendors would be glad to work with you. As Howard and others have said, don't fall into the traps that DCE and AD have falling into of tightly combining authentication and authorization into a single server. Andrew Bartlett wrote: > > Perhaps we should make something clear from the outset. Just as > Samba4's LDAP server is not intended to be a world-class (or even > standards-conforming) LDAP server, I'm targeting our KDC as a match for > the Microsoft interface, not as the new gold standard for KDCs in POSIX. > > I'm trying to fill the space currently filled by Microsoft's Active > Directory, not trying (particularly in the first release of Samba4) to > replace an existing corporate Kerberos infrastructure. > > Now, I come at this whole area from rather a different direction than I > suspect you do, because I'm not steeped in the history of Kerberos, nor > do I run a large and complex site that uses it. What is custom about > your kerberos setup, and given that I realise that having multiple > kerberos realms is the pits, what could we do to make your life easier? > > > > Well, it will always be open source, so unlike AD you can hack it > however you please :-) > > My observation is that sites fit into one of the these three boxes: > > (98%) Never used Kerberos, or don't know what Kerberos is: > - NT4 sites > - Samba3 based sites > - Low-clue AD networks (you don't need to understand Kerberos to use > AD) > - Everybody else (most linux networks, workgroups) > > (~1.75%) Large sites, which run AD, know what kerberos is and use it to > their advantage > > (<.25%) Sites that chose to use unix-based kerberos systems, and have > integrated it properly into a majority of their systems. > > My problem is that while I do *not* wish to exclude anybody, I need to > care about the first two categories far more than the clued-in SysAdmin > of a real kerberos site. (Where I think that long-term, we can work > something out). > > Andrew Bartlett > > > > ------------------------------------------------------------------------ > > _______________________________________________ > krbdev mailing list [hidden email] > https://mailman.mit.edu/mailman/listinfo/krbdev -- Douglas E. Engert <[hidden email]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
In reply to this post by Howard Chu
On Tue, May 24, 2005 at 07:32:30AM -0700, Howard Chu wrote:
> > Nobody is going to just drop it in and turn it on > and go merrily on their way. Not even Windows administrators. Yes they are. *Especially* Windows administrators :-). Really. You're living in a different, self-selected world than we are. Samba *3* is currently much too hard to use for most people, and it does much less than Samba4. > Some times, hordes of annoying questions can be a good motivator for > projects to improve their docs and/or ease-of-use. It certainly exposes > weak spots... You've ignored them so far, why would it change now ? :-). I worked on Kerberos 5 back in 1997. It was hard to use then, and it's hard to use now. Error messages are opaque and troubleshooting tools virtually non-existant. I did do a rant about it on comp.protocols.kerberos once and Sam rightly told me to stop whining and help fix it :-). But I currently don't have the time. But Samba4 needs to be as easy to use and install as W2K. If it isn't it will fail. Jeremy. _______________________________________________ krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev |
Free forum by Nabble | Edit this page |