Samba4 and Heimdal Kerberos dependencies
abartlet at samba.org
Wed Feb 9 09:43:16 GMT 2005
On Wed, 2005-02-09 at 11:04 +1100, Andrew Tridgell wrote:
> I think that making us dependent on Heimdal if we are an ADS DC is
> acceptable for the moment, given that we don't have much choice.
> I think it is critical that we _not_ be dependent on Heimdal if we are
> not an ADS DC. So if we are an ADS member server, or a NT4 style DC,
> or a standalone server then we must be able to build and be fully
> functional without Heimdal and without MIT kerberos. If that means we
> have to duplicate some SPNEGO and GSSAPI code then so be it.
I would be very careful about how we define 'fully functional' and each
of those roles, but I don't see any issue here. An NTLM-only system
covers two of your three examples, but when it regards ADS membership,
we get into semantics. However, as you will see in my comments below, I
don't see even 'ADS membership' as being a major issue, as long as we
are clear on what we can and can't do.
> This is something that needs to be watched carefully. It would be all
> too easy for developers that do have Heimdal to introduce a dependency
> that either makes Samba4 not work at all or work only in a crippled
> fashion when Heimdal is not present.
I expect that we will function is a reduced fashion - but that this
should be well designed, and that we use Samba 3.0 as the rough
benchmark for what minimum facilities should be available on a given set
of Kerberos/GSSAPI pre-requisites.
If we have learnt anything about this protocol over the years, we have
learnt that that it is about choice - and even without any Kerberos
whatsoever, there will always be NTLM.
However, to example what I mean by matching Samba 3.0: I expect that we
will continue to use our current implementation of SPNEGO and 'GSSAPI'
for CIFS session setups (client and server). These have a particular
requirement that we extract the kerberos session key, and are also
critical operations to most Samba installations. Fortunately, the
operations that come up here are reasonably simple, as exampled by the
fact that Samba3 deals with it.
Indeed, I wonder if it may be possible to actually make some parts of
this puzzle simpler than even Samba3 makes it. (I don't think SPNEGO is
quite as mandatory as Samba3 assumes it to be, when the only option is
But where we go beyond what Samba3 provides, I think we should be more
cautious, and use the libraries we have available. For example, I see
roles beyond what Samba3 does, that do not fall directly into the
category of 'ADS server'. In particular, the use of GSSAPI/Kerberos to
sign and seal an LDAP connection, or a DCE-RPC connection. (Samba3 is
unable to do this).
I intend to address these concerns about an added dependency in a number
My hope is that we can actually bundle Heimdal Kerberos into the actual
Samba install, as an integral part of the build process. Assuming it is
no less portable than the rest of Samba (a point I need to test by
submission to the build farm).
If this is not possible, then my proposal is for Heimdal to become an
optional but highly recommended dependency, with the limitations
described above. By testing the portability of Heimdal on the build
farm, we should be able to obtain better guidance in deciding what
'extra' features may or may not be available without it.
In the short term, I don't expect anything much to change. But I don't
want folks to claim sudden surprise when I propose that to solve certain
problems (particularly as we research the Win2k3 DC membership, and
DRSUAPI), we need to use this kind of a solution.
My next short-term goal will be to improve the optional gensec_gssapi
module, to better exploit both the capabilities of MIT and Heimdal
kerberos. This is still at 'proof of concept' stage - no earth-
shattering movements are proposed. If I have designed GENSEC well, this
this will be the only module with an explicit dependency on Heimdal.
(BTW, I expect to add a much more optional dependency on Cyrus-SASL, to
handle some other password types, and to prove that GENSEC can be
arbitrarily expanded in that way).
I hope this clarifies that technical side of the situation a little
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/68239cdf/attachment.bin
More information about the samba-technical