Hi, I'm not sure which % I represent, but something that hit me is that this is
about configuration management and ways to test things.
To get a simple Samba AD system up and running, you do not only need a KDC, but
you also need a set of DNS adresses and (?) a DHCP server with Kerberos support
as well as a working pam/nsswitch configuration. The possibilities for errors
in different configurationfiles are huge.
I think that to help the 98% of the users you'll need a simple testutility to
find out if all needed prerequisites has been set up and are working correctly
- the error might be in smb.conf itself for all you know.
Apart from that, controlling the KDC probably helps - I leave this issue to
> 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
> > - 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 krbdev@xxxxxxx
> Douglas E. Engert <DEEngert@xxxxxxx>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444