Release Announcements
=====================
-This is the first pre release of Samba 4.17. This is *not*
+This is the first pre release of Samba 4.21. This is *not*
intended for production environments and is designed for testing
purposes only. Please report any defects via the Samba bug reporting
system at https://bugzilla.samba.org/.
-Samba 4.17 will be the next version of the Samba suite.
+Samba 4.21 will be the next version of the Samba suite.
UPGRADING
=========
+LDAP TLS/SASL channel binding support
+-------------------------------------
-NEW FEATURES/CHANGES
-====================
-
-Configure without the SMB1 Server
----------------------------------
-
-It is now possible to configure Samba without support for
-the SMB1 protocol in smbd. This can be selected at configure
-time with either of the options:
-
---with-smb1-server
---without-smb1-server
-
-By default (without either of these options set) Samba
-is configured to include SMB1 support (i.e. --with-smb1-server
-is the default). When Samba is configured without SMB1 support,
-none of the SMB1 code is included inside smbd except the minimal
-stub code needed to allow a client to connect as SMB1 and immediately
-negotiate the selected protocol into SMB2 (as a Windows server also
-allows).
-
-None of the SMB1-only smb.conf parameters are removed when
-configured without SMB1, but these parameters are ignored by
-the smbd server. This allows deployment without having to change
-an existing smb.conf file.
-
-This option allows sites, OEMs and integrators to configure Samba
-to remove the old and insecure SMB1 protocol from their products.
-
-Note that the Samba client libraries still support SMB1 connections
-even when Samba is configured as --without-smb1-server. This is
-to ensure maximum compatibility with environments containing old
-SMB1 servers.
-
-Bronze bit and S4U support with MIT Kerberos 1.20
--------------------------------------------------
-
-In 2020 Microsoft Security Response Team received another Kerberos-related
-report. Eventually, that led to a security update of the CVE-2020-17049,
-Kerberos KDC Security Feature Bypass Vulnerability, also known as a ‘Bronze
-Bit’. With this vulnerability, a compromised service that is configured to use
-Kerberos constrained delegation feature could tamper with a service ticket that
-is not valid for delegation to force the KDC to accept it.
-
-With the release of MIT Kerberos 1.20, Samba AD DC is able able to mitigate the
-‘Bronze Bit’ attack. MIT Kerberos KDC's KDB (Kerberos Database Driver) API was
-changed to allow passing more details between KDC and KDB components. When built
-against MIT Kerberos, Samba AD DC supports MIT Kerberos 1.19 and 1.20 versions
-but 'Bronze Bit' mitigation is provided only with MIT Kerberos 1.20.
+The ldap server supports SASL binds with
+kerberos or NTLMSSP over TLS connections
+now (either ldaps or starttls).
-In addition to fixing the ‘Bronze Bit’ issue, Samba AD DC now fully supports
-S4U2Self and S4U2Proxy Kerberos extensions.
+Setups where 'ldap server require strong auth = allow_sasl_over_tls'
+was required before, can now most likely move to the
+default of 'ldap server require strong auth = yes'.
-Resource Based Constrained Delegation (RBCD) support
-----------------------------------------------------
+If SASL binds without correct tls channel bindings are required
+'ldap server require strong auth = allow_sasl_without_tls_channel_bindings'
+should be used now, as 'allow_sasl_over_tls' will generate a
+warning in every start of 'samba', as well as '[samba-tool ]testparm'.
-Samba AD DC built with MIT Kerberos 1.20 offers RBCD support now. With MIT
-Kerberos 1.20 we have complete RBCD support passing Sambas S4U testsuite.
-Note that samba-tool lacks support for setting this up yet!
+This is similar to LdapEnforceChannelBinding under
+HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
+on Windows.
-To complete RBCD support and make it useful to Administrators we added the
-Asserted Identity [1] SID into the PAC for constrained delegation. This is
-available for Samba AD compiled with MIT Kerberos 1.20.
+All client tools using ldaps also include the correct
+channel bindings now.
-[1] https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview
-Customizable DNS listening port
--------------------------------
-
-It is now possible to set a custom listening port for the builtin DNS service,
-making easy to host another DNS on the same system that would bind to the
-default port and forward the domain-specific queries to Samba using the custom
-port. This is the opposite configuration of setting a forwarder in Samba.
-
-It makes possible to use another DNS server as a front and forward to Samba.
-
-Dynamic DNS updates may not be proxied by the front DNS server when forwarding
-to Samba. Dynamic DNS update proxying depends on the features of the other DNS
-server used as a front.
-
-CTDB changes
-------------
-
-* When Samba is configured with both --with-cluster-support and
- --systemd-install-services then a systemd service file for CTDB will
- be installed.
-
-* ctdbd_wrapper has been removed. ctdbd is now started directly from
- a systemd service file or init script.
-
-* The syntax for the ctdb.tunables configuration file has been
- relaxed. However, trailing garbage after the value, including
- comments, is no longer permitted. Please see ctdb-tunables(7) for
- more details.
+NEW FEATURES/CHANGES
+====================
-Operation without the (unsalted) NT password hash
--------------------------------------------------
+LDB no longer a standalone tarball
+----------------------------------
-When Samba is configured with 'nt hash store = never' then Samba will
-no longer store the (unsalted) NT password hash for users in Active
-Directory. (Trust accounts, like computers, domain controllers and
-inter-domain trusts are not impacted).
+LDB, Samba's LDAP-like local database and the power behind the Samba
+AD DC, is no longer available to build as a distinct tarball, but is
+instead provided as an optional public library.
-In the next version of Samba the default for 'nt hash store' will
-change from 'always' to 'auto', where it will follow (behave as 'nt
-hash store = never' when 'ntlm auth = disabled' is set.
-
-Security-focused deployments of Samba that have eliminated NTLM from
-their networks will find setting 'ntlm auth = disabled' with 'nt hash
-store = always' as a useful way to improve compliance with
-best-practice guidance on password storage (which is to always use an
-interated hash).
+If you need ldb as a public library, say to build sssd, then use
+ ./configure --private-libraries='!ldb'
-Note that when 'nt hash store = never' is set, then arcfour-hmac-md5
-Kerberos keys will not be available for users who subsequently change
-their password, as these keys derive their values from NT hashes. AES
-keys are stored by default for all deployments of Samba with Domain
-Functional Level 2008 or later, are supported by all modern clients,
-and are much more secure.
+This re-integration allows LDB tests to use the Samba's full selftest
+system, including our knownfail infrastructure, and decreases the work
+required during security releases as a coordinated release of the ldb
+tarball is not also required.
-Finally, also note that password history in Active Directory is stored
-in nTPwdHistory using a series of NT hash values. Therefore the full
-password history feature is not available in this mode.
+This approach has been demonstrated already in Debian, which is already
+building Samba and LDB is this way.
-To provide some protection against password re-use previous Kerberos
-hash values (the current, old and older values are already stored) are
-used, providing a history length of 3.
+As part of this work, the pyldb-util public library, not known to be
+used by any other software, is made private to Samba.
-There is one small limitation of this workaround: Changing the
-sAMAccountName, userAccountControl or userPrincipalName of an account
-can cause the Kerberos password salt to change. This means that after
-*both* an account rename and a password change, only the current
-password will be recognised for password history purposes.
+LDB Module API Python bindings removed
+--------------------------------------
+The LDB Modules API, which we do not promise a stable ABI or API for,
+was wrapped in python in early LDB development. However that wrapping
+never took into account later changes, and so has not worked for a
+number of years. Samba 4.21 and LDB 2.10 removes this unused and
+broken feature.
REMOVED FEATURES
================
-LanMan Authentication and password storage removed from the AD DC
------------------------------------------------------------------
-
-The storage and authentication with LanMan passwords has been entirely
-removed from the Samba AD DC, even when "lanman auth = yes" is set.
smb.conf changes
================
Parameter Name Description Default
-------------- ----------- -------
- dns port New default 53
- nt hash store New parameter always
+ ldap server require strong auth new values
KNOWN ISSUES
============
-https://wiki.samba.org/index.php/Release_Planning_for_Samba_4.17#Release_blocking_bugs
+https://wiki.samba.org/index.php/Release_Planning_for_Samba_4.21#Release_blocking_bugs
#######################################
git.samba.org / samba.git / blobdiff