Notice: samba 4.0 beta1 and what will be available in Fedora

Alexander Bokovoy abokovoy at
Tue Jun 5 15:13:14 UTC 2012


Samba team has released Samba 4.0 beta 1 today. This is important
milestone in a more than 8 years of Samba 4 development.

This mail attempts to explain what will be and will not be available in
Fedora (Rawhide first,,
we are considering to discuss with all affected maintainers if and how an
update to F17 would be possible).

Sorry for longer than perhaps needed write up as this topic wasn't covered
before apart from discussions in Samba and FreeIPA upstreams.

Samba 4 is a combined set of daemons, client utilities, and Python
bindings that allow communicating using SMB1, SMB2, and soon SMB3
protocols. It also implements Active Directory domain controller (DC)
functionality as an integrated Kerberos DC, LDAP server, DNS server, 
and SMB/CIFS server.

Samba 4 AD DC functionality relies heavily on Heimdal Kerberos
implementation. Samba 4 includes the embedded Heimdal, if your system
misses it, like we have in Fedora. When embedded Heimdal is in use,
all Samba 4 code is compiled against this Kerberos implementation,
including client side libraries and tools, and traditional file serving
smbd daemon we know as 'samba' package in Fedora.

Fedora uses MIT Kerberos implementation, both server and client side.
Heimdal and MIT Kerberos are targetting to implement the same Keberos V
protocol but have their own extensions API and certain semantical
differences. They also have slightly different meaning to Kerberos
credential cache files format where Kerberos-aware applications store
their Kerberos keys. While this is not an issue for client-server 
communication over a network (a Heimdal client does talk the same
Kerberos V protocol that MIT Kerberos server understands and vice
versa), interoperability of the client or server code using the same
credential cache files on the same system is much less supported for
advanced features like S4U2Proxy and S4U2Self.

It is generally not advisable to load two different API implementations
into the same address space either. When the rest of the system
libraries is compiled against MIT Kerberos, use of them within Samba 4
code brings in MIT Kerberos as well. This happens, for example, when
linking against OpenLDAP client libraries and using SASL authentication.

As part of work we are doing on FreeIPA v3, we have made possible to
compile Samba 4 code against MIT Kerberos implementation. Unfortunately,
MIT Kerberos does not give option of embedding Kerebros KDC server within
another process which is required for Samba 4 AD DC functionality. Thus,
when compiled with MIT Kerberos, Samba 4 currently does not provice Active
Directory Domain Controller functionality at all, only client side
libraries and tools to the extent that does not involve AD DC
operations. Also, smbd is compiled against MIT Kerberos and provides
functionality equivalent to what is provided by Samba 3's smbd.

We are intending to make possible use of AD DC functionality with MIT
Kerberos but this is longer term project that requires cooperation
between Samba, MIT, and FreeIPA.

For GNU/Linux-based clients FreeIPA already provides functionality
similar to the one of Active Directory. With FreeIPA v3 we'll have
cross-realm trusts support with Active Directory that will allow
seamlessly integrating GNU/Linux-based machines into existing AD-based
infrastructure. You can get details about implementation from our talk
at SambaXP 2012 conference ( and
earlier roadmap talk at Fedora Devconf in Brno in February 2012

One consequence of Samba 4 built with MIT Kerberos is that Openchange
server code will not be working in Fedora either. Openchange server code
requires working Samba 4 DC server with proper AD provisioning. This only
affects server side and does not affect Openchange client side support
which is used in Evolution MAPI plugin, which will continue to work.

Rawhide is already providing Samba 4  built with MIT Kerberos,
and Openchange package was modified to include only client side support.
The latter also submitted and merged to Openchange upstream.

What is available in Rawhide right now?

* samba4-* 4.0.0-53beta1 packages are built against system-wide MIT Kerberos 
   libraries. These packages are made conflicting with samba-* packages in areas
   where they provide the same binaries and/or libraries. You don't need
   to install samba4-* packages unless you want to use Evolution MAPI
   plugin and (soon FreeIPA v3 server).

* openchange is built to provide client-side libraries to allow Evolution
   MAPI plugin to work.

* Evolution MAPI plugin is rebuilt against new openchange build.

What will not be available in Rawhide in time for Fedora 18?

* Samba 4 AD DC implementation

What about samba and samba4 packages?

As samba4 is a superset of Samba 3 packages in Fedora, we are also
considering to discuss renaming samba4 back to samba. As all existing
API and ABI for smbd/nmbd/winbindd and libsmbclient library will be the
same, the switch is not going to be problematic. However, there is still
need to stabilize code through beta and pre-releases before doing that.

We also intend to work with upstream and other distributions on making
common set of instructions on configuring and setting up different
facets of Samba (AD DC, file server, member server, ...).

Why update to Fedora 17 would be preferred?

Samba 4 in Fedora 17 release is still built against Heimdal Kerberos
implementation as we haven't finished MIT Kerberos support before
alpha21 and Fedora 17 includes alpha18. Therefore, all kinds of issues
may appear when Samba 4 client code is used in MIT Kerberos environment,
particularly when Evolution MAPI plugin is used together with LDAP.

However, updating Samba 4 to 4.0 beta 1 in Fedora 17 will also require
updating libldb and libtdb and its users, primarily SSSD and Openchange.
We have the rebuild of libtdb, libldb, and SSSD available in IPA development
repository ( for Fedora 17
already, no issues are detected.

More detailed description of Samba 4 MIT build and issues of mixing
different Kerberos implementations is available at

/ Alexander Bokovoy

More information about the devel mailing list