Greetings! Всех, кто может быть затронут изменениями в Kerberos-related подсистеме Сизифа, прошу прочитать пересылаемое и поделиться информацией по следующим вопросам: - готовы ли ваши пакеты, использующие MIT krb5, быть собранными с Heimdal? - готовы ли администраторы существующих KDC на основе MIT krb5 в Сизифе/Мастере к переезду на Heimdal в обозримом будущем (matter of weeks/months)? ----- Forwarded message from Andrew Bartlett ----- Date: Wed, 09 Feb 2005 06:51:05 +1100 From: Andrew Bartlett 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/