Samba4 and Heimdal Kerberos dependencies
abartlet at samba.org
Tue Feb 8 19:51:05 GMT 2005
Over recent weeks/months, there has been discussion and development of
the Kerberos infrastructure in Samba4. This has led to the point where
it does not appear viable to recreate the development effort of a
Kerberos and GSSAPI implementation simply to gain independence from the
choice of library on the target machine.
Note that we have moved down this path ever since we started on the KDC
integration with Heimdal, but I am now proposing that we depend on the
libraries as well as the installation of the KDC. We will however
provide support such that a simple file server can operate, much as
Samba3 does, on a wider variety of system libraries.
I wish to propose that a fully functional Samba4 installation will
require, as an explicit dependency, an appropriate (modified) snapshot
of Heimdal Kerberos. This comes about from these angles:
For Samba4 to complete it's stated goal of being an Active Directory
Domain Controller, we need the KDC to query our user database, enforce
access controls as appropriate and to issue tickets on that basis.
In the modified version of Heimdal found in 'lorikeet/heimdal', we plug
into the database abstraction layer (hdb) to provide a link to ldb. In
the future, we will also need to figure out how and were to integrate
the PAC support, as well as handle password changes.
As we continue to develop Samba4, it becomes clear that we will need
much more of a GSSAPI implementation than Samba3 ever possessed. We
have already overhauled the SPNEGO code, and while this is functional,
the requirements of the new 'secure' SPNEGO will require changes and
For LDAP and DCE-RPC, we need to understand and implement GSSAPI signing
and sealing of data, not just the thin shim of GSSAPI required for
authentication. I do not wish to duplicate this security-critical (and
cryptographic) code, if I can avoid it.
While GSSAPI is common between many implementations, we also need access
to functions added to Heimdal by PADL, for their AD implementation (such
as gsskrb5_extract_authz_data_from_sec_context()). This example allows
us, as a server, to extract the PAC from an incoming request, without
needing to separately parse the GSSAPI wrapping.
We should also consider the matter of threading (for the server-side
threaded process modal), where the conventional wisdom on the OpenLDAP
lists appears to indicate that Heimdal handles these better:
Heimdal snapshots also support the newer AES encryption types, and I see
a particular advantage to avoiding the mess that we have endured in
Samba3, where we were at the mercy of the system libs in support for
With a few bugfixes in recent times, it is now possible to install
Heimdal kerberos in a separate prefix (the default is /usr/heimdal), and
to link Samba4 against it, even while the rest of the system may use
MIT. Provided we don't get a dependency on OpenSSL, and provided
Heimdal is not linked with OpenSSL, it all appears to work.
Build System Magic
While I consider it an acceptable solution to simple require that
Heimdal be installed into a suitable prefix before the Samba4 build
process starts, it would certainly be highly preferable for the build
system to handle this itself, much as it does the use use of 'popt',
Working relationship with the Heimdal Team
One of the key points I have found to be of particular value in our
choice to use Heimdal has simply been the working relationship we have
with the Heimdal developers. Where sensible, the patches we have made
to Heimdal have already been included upstream, and a great deal of time
has been spent in assisting our understanding of Kerberos, and the
changes we are making to it.
Why not MIT too?
While it would no doubt be technically possible to modify MIT to handle
a similar database abstraction layer, and to add all the other hooks
required, the duplication of effort does not at this stage seem
worthwhile. (We are yet to get the Heimdal version fully operable).
For a long as we can install Heimdal separate to the system libraries, I
see no benefit to using the system libs, and certainly none in also
supplying MIT libs.
These points were explicitly discussed on IRC a couple of weeks ago,
where two main points were raised:
- (vl) Using just one Keberos implementation will save us a lot of pain
- (lieschen) Distributors won't enjoy having the dependency (and the
need to update the samba-specific Heimdal snapshot in the event of a
However, the general mood appeared in favor, particularly assuming our
build wizards get Heimdal statically linked into the main Samba build.
I hope this gets the issue into more of a public arena, so that we can
get more feedback (we will have to release this at some point, and no
matter what we choose, I'm sure we will regret part of it), as well as
to avoid surprising too many folks when we do so...
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050209/31647911/attachment.bin
More information about the samba-technical