ALT Linux Sisyphus discussions
 help / color / mirror / Atom feed
From: Alexander Bokovoy <ab@altlinux.org>
To: devel@altlinux.ru
Cc: sisyphus@altlinux.ru
Subject: [sisyphus] Fw: Samba4 and Heimdal Kerberos dependencies
Date: Wed, 9 Feb 2005 19:08:26 +0300
Message-ID: <20050209160825.GA13042@altlinux.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 6523 bytes --]

Greetings!

Всех, кто может быть затронут изменениями в Kerberos-related подсистеме
Сизифа, прошу прочитать пересылаемое и поделиться информацией по следующим
вопросам:

	- готовы ли ваши пакеты, использующие MIT krb5, быть собранными с
	  Heimdal?

	- готовы ли администраторы существующих KDC на основе MIT krb5 в
	  Сизифе/Мастере к переезду на Heimdal в обозримом будущем (matter
	  of weeks/months)?


----- Forwarded message from Andrew Bartlett <abartlet@samba.org> -----

Date: Wed, 09 Feb 2005 06:51:05 +1100
From: Andrew Bartlett <abartlet@samba.org>
To: samba-technical@samba.org
Cc: 
Subject: Samba4 and Heimdal Kerberos dependencies

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:

KDC
---

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.

Kerberos Client/Server
----------------------

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
extensive testing.  

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:
http://www.openldap.org/lists/openldap-software/200403/msg00199.html

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
arcfour-hmac-md5.

Heimdal Installation
--------------------

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',
when unavailable.  

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.

IRC Discussion
--------------
http://samba.sernet.de/irclog/2005/01/20050124-Mon.log

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
security issue).

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

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net



----- End forwarded message -----

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2005-02-09 16:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050209160825.GA13042@altlinux.org \
    --to=ab@altlinux.org \
    --cc=devel@altlinux.ru \
    --cc=sisyphus@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Sisyphus discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \
		sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru
	public-inbox-index sisyphus

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.sisyphus


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git