WHATSNEW: Start release notes for Samba 4.18.0pre1.

Signed-off-by: Jule Anger <janger@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>

1 files changed, 3 insertions, 141 deletions

diff --git a/WHATSNEW.txt b/WHATSNEW.txt
index d39748f0587..c9cd84faa26 100644
--- a/WHATSNEW.txt
+++ b/WHATSNEW.txt
@@ -1,12 +1,12 @@
 Release Announcements
 =====================
 
-This is the first release candidate of Samba 4.17.  This is *not*
+This is the first pre release of Samba 4.18.  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.18 will be the next version of the Samba suite.
 
 
 UPGRADING
@@ -16,160 +16,22 @@ UPGRADING
 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.
-
-In addition to fixing the ‘Bronze Bit’ issue, Samba AD DC now fully supports
-S4U2Self and S4U2Proxy Kerberos extensions.
-
-Resource Based Constrained Delegation (RBCD) support
-----------------------------------------------------
-
-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!
-
-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.
-
-[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.
-
-Operation without the (unsalted) NT password hash
--------------------------------------------------
-
-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).
-
-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).
-
-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.
-
-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.
-
-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.
-
-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.
-
 
 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
 
 
 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.18#Release_blocking_bugs
 
 
 #######################################