Current ideas on kerberos requirements for Samba4

Wyllys Ingersoll wyllys.ingersoll at
Tue May 24 19:14:54 EDT 2005

I work for one of the "Vendors" described earlier and I am
uncomfortable with the idea that SAMBA would include their
own KDC.

My thoughts when I first read this thread were much like what
Doug has suggested - instead of creating a whole new KDC,
why not open up some interfaces on both sides - other KDCs
(MIT, Heimdal) and in SAMBA so that the necessary communication
can be exchanged and SAMBA can integrate with pre-existing
KDCs.   I know there are alot of people in the Kerberos
community that would probably be able to help define these
interfaces and make sure that they get implemented
by the various implementors.

By having SAMBA provide a new KDC puts people currently using
MIT or Heimdal in the same position that they are today with
AD - they must maintain 2 KDC and REALMS or drop their
existing KDC infrastructure (MIT or Heimdal) and go with

Anyway, I applaud your efforts in the area of making a
fully compliant AD-like server, but I am not so supportive
of creating yet another KDC and further fracturing the
Kerberos community by forcing a choice like this.

-Wyllys Ingersoll

Douglas E. Engert wrote:
> 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.

More information about the krbdev mailing list