Current ideas on kerberos requirements for Samba4

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Williams schrieb:
> On Tue, May 24, 2005 at 07:14:54PM -0400, Wyllys Ingersoll wrote:
> 
>>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
>>SAMBA.
>>
>>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.
> 
> 
> What Wyllys said.
> 
> The Samba team can go and do what they like -- there's plenty of KDC
> source code with sufficiently friendly licensing to go around.  But I'd
> much rather see cooperation (and cooperate) in the design of pluggable
> interfaces for KDCs, such as pluggable backends, pluggable
> pre-authentication provides, and pluggable authorization-data providers
> (particularly AD-KDCIssued containees), and later, when extensions comes
> along, pluggable ticket extensions providers.

yep, I think that is what we are aiming for...
and just also an interface to hook into the kdc packet parse functions,
so that we can controll the network interface and raw data from the wire in our
async event driven infrastructure...

so the design would be like this:

[wire] -> [samba socket lib] -> [samba kdc server service] -> [KDC library]
[wire] <- [samba socket lib] <- [samba kdc server service] <- [KDC library]

or as alternative if the admin wants to run the kdc seperate, he just starts the [KDC binary]
which is internally also uses its [KDC library], and on some Platforms/Systems the Vendors
can make the [KDC library] shared. So for security updates just need an update of the shared library.

- From the [KDC library] it looks like this:

[KDC library]-> [db backend] -> [samba ldb backend]
[KDC library]-> [pre-auth]   -> [samba pre-auth backend]
[KDC library]-> [auth-data]  -> [samba auth-data backend]
...

- --
metze

Stefan Metzmacher <metze at samba.org> www.samba.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClrdxm70gjA5TCD8RAp+7AKCYBQhYCMr6oPgqLVuR39AzPfiOHwCeOb01
bF/uOkVcqDeu9Xi+V2XlayQ=
=8PSt
-----END PGP SIGNATURE-----