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 krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


--

Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444