Difference between revisions of "Updating Samba"

(Fixing the replPropertyMetaData attributes (updating from < 4.5.0))
(Upgrading Active Directory Domain Controllers)
 
(38 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
This is a general documentation on how to update a Samba installation.
+
The following documentation describes the process of updating Samba to a newer version.
  
 +
If you want to migrate a Samba NT4 domain to Samba Active Directory (AD), see [[Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)|Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade)]].
  
 +
{{Imbox
 +
| type = note
 +
| text = Microsoft stopped supporting Windows NT 4.0 on December 31, 2004 and twice recently they have broken compatibility to it in Windows 10. It is probably just a matter of time until they decide not to fix a break. Samba, like Microsoft, advises upgrading to Active Directory.
 +
}}
  
  
  
= Common misconceptions about Samba 4 =
 
  
One of the common misconceptions is, that <u>Samba 4 automatically means „Active Directory only“: '''That's wrong!'''</u>
 
  
Acting as a Active Directory Domain Controller is one of the enhancements, included in Samba 4. But version 4 is also just the next release after the 3.6 series and contain all features of the previous ones - including the NT4-style (classic) domain support. This means you can [[#Update_process|update a Samba 3.x NT4-style PDC to 4.x]], like you've updated it in the past (e. g. from 3.4.x to 3.5.x). You won't move your NT4-style domain to an Active Directory automatically!
+
= Misconceptions About Samba 4 =
  
And of course the possibility remains unchanged, to setup a new NT4-style PDC with Samba 4.x, like done in the past (e. g. with openLDAP backend). Active Directory support in Samba 4 is additional and does not replace any of these features. We do understand the difficulty presented by existing LDAP structures and for that reason there isn't a plan to decommission the classic PDC support. It remains tested by the continuous integration system.
+
{{Imbox
 +
| type = note
 +
| text = If you update to Samba 4 and later, you do not have to migrate to Active Directory.
 +
}}
  
The code that supports the classic Domain Controller is also the same code that supports the internal 'Domain' of standalone servers and Domain Member Servers. This means that we still use this code, even when not acting as an AD Domain Controller. It is also the basis for some of the features of FreeIPA and so it gets development attention from that direction as well.  
+
The Active Directory (AD) Domain Controller (DC) support is one of the enhancements introduced in Samba 4.0. However all newer versions include the features of previous versions - including the NT4-style (classic) domain support. This means you can [[#The_Update_Process|update]] a Samba 3.x NT4-style primary domain controller (PDC) to a recent version, as you previously updated, for example from 3.4.x to 3.5.x. There is no need to migrate an NT4-style domain to an AD.
  
 +
Additionally, all recent versions continue to support setting up a new NT4-style PDC. The AD support in Samba 4.0 and later is optional and does not replace any of the PDC features. The Samba team understand the difficulty presented by existing LDAP structures. For that reason, there is no plan to remove the classic PDC support. Additionally we continue testing the PDC support in our continuous integration system.
  
  
  
  
= Migrating a Samba NT4-style domain to Samba Active Directory =
 
  
If you plan to migrate a Samba NT4 domain to Samba Active Directory, you should follow the [[Setup_a_Samba_Active_Directory_Domain_Controller|Samba AD DC HowTo]] and the [[Migrating_a_Samba_NT4_domain_to_a_Samba_AD_domain_(classic_upgrade)|Classicupgrade HowTo]] instead!
+
= The Update Process =
  
 +
Run the following steps, whether you are updating a Samba Active Directory (AD) domain controller (DC), a Samba NT4-style PDC, a Samba domain member, or a standalone installation:
 +
 +
* Stop all Samba services.
 +
 +
* Create a backup.
 +
 +
* Read the release notes of skipped versions. They contain important information, such as new features, changed parameter, and bug fixes. In case you switch to new major release, read the release notes of the initial version (x.y.0) and the ones from minor versions up to the new version you will update to. For example, if you update from 4.4.4 to 4.6.2, read the 4.5.0, 4.6.0, 4.6.1, and 4.6.2 release notes.
 +
 +
* Install the latest version over your existing one:
 +
 +
:* If you compile Samba from the sources, use the same <code>configure</code> options as used for your previous version. For more information, see [[Build_Samba_from_Source#Viewing_Built_Options_of_an_Existing_Installation|Build Samba From the Sources]].
 +
 +
:* If you update using packages, read the distribution documentation for information how to update.
 +
 +
* Start Samba.
 +
: Start the same daemons as on your previous version:
 +
:* On Samba AD DCs: <code>samba</code>
 +
:* On Samba NT4-style PDC/BDCs: <code>smbd</code>, <code>nmbd</code>
 +
:* On Samba domain members: <code>smbd</code>, <code>nmbd</code> (<code>winbind</code>, if used)
 +
:* On Samba standalone hosts: <code>smbd</code>
 +
 +
* Check your Samba log files for errors.
 +
 +
* Test your updated installation.
 +
 +
 +
= Upgrading Active Directory Domain Controllers =
 +
 +
Upgrading your AD DCs can introduce additional complications, due to things like database compatibility and managing FSMO roles. We recommend that you:
 +
* Run the [[dbcheck|Samba AD DC database check]] as part of testing your updated installation.
 +
* Refer to [[Upgrading_a_Samba_AD_DC#Updating_Multiple_Samba_Domain_Controllers|Updating_Multiple_Samba_Domain_Controllers]] for the safest way to roll out an upgrade to your DC network.
 +
* Be aware of database compatibility when [[downgrading an Active Directory DC]] across a major release.
 +
<br>
 +
 +
= Notable Enhancements and Changes =
 +
 +
If you are updating Samba, always read the [[Samba_Features_added/changed_(by_release)|release notes]] of all versions between the previous and the one you are updating to. They contain important and additional information on new features, changed parameter options, and so on.
 +
 +
This section provides an overview about important changes that require your attention to fix problems of previous versions, avoid a negative performance impact, and so on.
  
  
  
 +
== Changes Affecting All Samba Installation Modes ==
  
= General notes =
+
=== File Execution Permissions ===
  
''Note: Samba 4 is just the next release after 3.6. Samba 4 doesn't mean „Active Directory only“. You can simply update your NT4-style domain to the latest 4x version, like you had installed updates in the past.''
+
'''4.0.0 and later'''
  
If the type of installation (Active Directory Domain Controller, NT4-style PDC, Member Server) does not change, you can simply follow the steps below to update.
+
Previously, Samba did not check the execution bit of files. As a consequence, users could execute files, such as <code>*.exe</code> and <code>*.bat</code>, on a share, if the x-bit was not set. Samba has been enhanced and now denies to execute a file if the x-bit is not set. In situations, such as when upgrading from a previous version, your executable files can be missing the x-bit. As a workaround, you can enable the old behaviour, if you set the following parameter for individual shares or in the <code>[global]</code> section:
  
 +
acl allow execute always = yes
  
  
  
 +
== Samba Active Directory Domain Controllers ==
  
= Best Practices Updating Multiple Samba Domain Controllers =
+
=== The <code>ntvfs</code> File Server Back End Has Been Disabled ===
  
When you plan to update multple Samba Active Directory Domain Controllers on your network, the recommended way is:
+
'''4.5.0 and later'''
  
* Update one of the Samba AD DCs, that is is not holding any FSMO role.
+
Previously, Samba enabled users to provision a domain controller (DC) using the <code>ntvfs</code> file server back end. This back end was never supported, and thus the <code>ntvfs</code> feature is no longer build by default in Samba 4.5.0. Consequently, starting the <code>samba</code> service on a DC using the <code>ntvfs</code> back end failed after the update and the following error is logged:
  
* Start Samba on the updated DC and check that the replication between all DCs work successful („samba-tool drs showrepl“).
+
[2016/09/01 08:00:00.000000,  0, pid=995] ../source4/smbd/service.c:98(server_service_startup)
 +
  Failed to start service 'smb' - NT_STATUS_INVALID_SYSTEM_SERVICE
 +
[2016/09/01 08:00:00.000000,  0, pid=995] ../lib/util/become_daemon.c:111(exit_daemon)
 +
  STATUS=daemon failed to start: Samba failed to start services, error code -1073741796
  
* Verify the installation, to ensure that the new version work like expected.
+
To fix the problem, migrate the file server back end on your DC to the supported <code>s3fs</code> back end. For details, see [[Migrating_the_ntvfs_File_Server_Back_End_to_s3fs|Migrating the ntvfs File Server Back End to s3fs]].
  
* Upgrade the other Samba DCs one at a time. Always make sure, that the replication is working properly.
 
  
  
 +
=== Fixing replPropertyMetaData Attributes ===
  
 +
'''4.5.0 and later'''
 +
 +
Samba versions prior to 4.5.0 stored the <code>replPropertyMetaData</code> attribute incorrectly. As a consequence, administrators could experience, for example, renaming conflicts. The problem has been fixed in 4.5.0 and later versions and Samba now stores the attribute correctly. The <code>samba-tool</code> utility has been enhanced to detect incorrectly stored <code>replPropertyMetaData</code> attributes:
 +
 +
# samba-tool dbcheck --cross-ncs
 +
 +
To fix the attributes, run:
 +
 +
# samba-tool dbcheck --cross-ncs --fix --yes
 +
...
 +
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000003
 +
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000000
 +
ERROR: unsorted attributeID values in replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
 +
 +
Fix replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com by sorting the attribute list? [YES]
 +
Fixed attribute 'replPropertyMetaData' of 'CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com'
  
 +
Note that the <code>--yes</code> parameter automatically fixes <u>all</u> problems found and not only the <code>replPropertyMetaData</code> attributes!
  
= Update process =
+
Run the check and fix operation on all Samba Domain Controllers (DC), because <code>replPropertyMetaData</code> is a non-replicated attribute and modifications are not replicated to other DCs.
  
The following steps are the same, regardless if you update a Samba AD DC, Samba NT4-style PDC or Samba Member Server.
+
For more information, see the [[Dbcheck|Samba AD DC database check]] section.
  
* Stop all Samba services.
+
=== Failure To Access Shares on Domain Controllers If <code>idmap config</code> Parameters Set in the <code>smb.conf</code> File ===
  
* Create a working backup!
+
'''4.4.6 or later'''
  
* Read all release notes of versions since the one you are updating from! They will contain important and useful information i.e. parameters that have changed.
+
The <code>winbindd</code> service on a Samba Active Directory (AD) domain controller (DC) automatically uses the IDs set in the Active Directory <code>uidNumber</code> and <code>gidNumber</code> attributes of user accounts and groups. If the attributes are not set, Samba generates IDs locally on the DC and stores them in the <code>idmap.ldb</code> database. Thus, on a Samba AD DC, <code>idmap config</code> parameters set in the <code>smb.conf</code> file were ignored. Due to a bug in Samba 4.4.6 and later, the parameters are no longer ignored and clients fail to connect to shares on the DC. To fix the problem:
 +
* Remove all <code>idmap config</code> parameters in the <code>smb.conf</code> file on DCs.
 +
* Restart the <code>samba</code> service.
 +
* Restart the clients.
  
* Install the latest version over your existing one.
+
As a result, clients now correctly connect to shares on the DC.
  
:* If you compile Samba from source, download the latest version from [http://www.samba.org http://www.samba.org]. If you use the same "configure" options as for your previous version, Samba will be installed over the old binaries and will find its databases in the same place. But always check if some configure options have changed and need to be adapted!
 
  
:* If you use packages, such as from [http://www.enterprisesamba.com/samba/ SerNet], check out the packagers information on how to install.
 
  
* Start Samba. You only have to start the same processes as you did before.
+
=== New Default for LDAP Connections Requires Strong Authentication ===
:* DC: samba
 
:* NT4-style PDC: smbd, nmbd
 
:* Member Server: smbd, nmbd (winbind, if you use it)
 
  
* Check your Samba logs for errors and problems.
+
'''4.4.1 or later / 4.3.7 or later / 4.2.10 or later'''
  
* Test your new installed version.
+
The security updates 4.4.1, 4.3.7 and 4.2.10 introduced a new <code>smb.conf</code> option for the Active Directory (AD) LDAP server to enforce strong authentication. The default for this new option <code>ldap server require strong auth</code> is <code>yes</code> and allows only simple binds over TLS encrypted connections. In consequence, external applications that connect to AD using LDAP, cannot establish a connection if they do not use or support TLS encrypted connections.
  
 +
Applications connecting to Samba AD using the LDAP protocol without encryption, will display the error message:
  
 +
ldap_bind: Strong(er) authentication required (8)
 +
        additional info: BindSimple: Transport encryption required.
  
 +
For further information, see the [https://www.samba.org/samba/history/samba-4.4.1.html 4.4.1], [https://www.samba.org/samba/history/samba-4.3.7.html 4.3.7], or the [https://www.samba.org/samba/history/samba-4.2.10.html 4.2.10] release notes.
  
  
= Update an early Samba 4 version on Samba Active Directory DCs =
 
  
Early versions of Samba 4 (Beta, RC, early 4.0.x) had some issues e. g. incorrect SysVol and directory ACLs. The following commands will fix these problems after you have updated.
+
=== AD Database Cleanup of Deleted LDAP DNS Entries ===
  
* Reset well known ACLs in AD (without "--fix", it will only check the ACLs)
+
'''4.1.12 or later'''
# samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
 
  
* Reset wrong SysVol ACLs (if you use the "sysvolcheck" option, it will check the ACLs instead)
+
Previously, Samba incorrectly created deleted Active Directory (AD) objects for removed DNS entries. The problem has been fixed. If you start the first Domain Controller (DC) with a fixed Samba version, all deleted objects are removed. As a result, this can result in a slow performance until the deleted objects are removed.
# samba-tool ntacl sysvolreset
 
  
* Fix errors in the AD database (without "--fix", it will only check for errors)
 
# samba-tool dbcheck --cross-ncs --fix
 
  
  
 +
=== Incorrect TLS File Permissions ===
  
 +
'''4.1.2 or later / 4.0.12 or later'''
  
 +
Previously, Samba created the <code>*.pem</code> files used for LDAP TLS encryptions with insecure permissions. To avoid insecure connections, delete the files on all domain controllers (DC):
  
= Other changes you should pay attention to, when updating =
+
# rm /usr/local/samba/private/tls/*.pem
  
== File execution permissions when upgrading from 3x to 4x ==
+
Restart Samba after you deleted the files to automatically re-create the new certificates.
  
See [[Shares_with_POSIX_ACLs#Execution_of_files|Execution of files]].
 
  
  
 +
=== Fixing Dynamic DNS Update Problems ===
  
== On Samba Active Directory DC's ==
+
'''4.0.7 or later'''
  
=== Fixing the replPropertyMetaData attributes (updating from < 4.5.0) ===
+
See [[Fix_DNS_dynamic_updates_in_Samba_versions_prior_4.0.7|Fix DNS dynamic updates in Samba versions prior 4.0.7]] for details.
  
Samba versions prior 4.5.0 stored the replPropertyMetaData attribute incorrectly. As a consequence, administrators could experience renaming conflicts or bad failure modes. The problem has been fixed in 4.5.0 and later versions and Samba now stores the attribute correctly. Additionally, samba-tool has been enhanced to detect incorrectly stored replPropertyMetaData attributes:
 
  
# samba-tool dbcheck --cross-ncs
 
  
To fix the attributes, run:
+
=== Fixing Incorrect Sysvol and Directory ACLs ===
  
# samba-tool dbcheck --cross-ncs --fix
+
''' When updating from early 4.0.x versions, 4.0 beta and 4.0 release candidates.'''
...
 
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000003
 
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000000
 
ERROR: unsorted attributeID values in replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
 
 
Fix replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com by sorting the attribute list? [YES]
 
Fixed attribute 'replPropertyMetaData' of 'CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com'
 
  
Because the replPropertyMetaData attribute is not replicated, you have to run the command on every AD DC in your forest. After a repair of all objects, run the command without the "--fix" option to verify a successful operation.
+
* To reset wrong Sysvol ACLs, run:
 +
# samba-tool ntacl sysvolreset
  
Please note that the repair operation requires some time to complete. For example: 3500 objects in 5 minutes (VM test environment: 1 vCPU, 1 GB RAM, HDD image located on SSSD).
+
* To reset all well known ACLs in the directory, run:
 +
# samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
  
 +
* To fix errors in the Active Directory (AD) database, run:
 +
# samba-tool dbcheck --cross-ncs --fix
  
 +
== Samba Domain Members ==
  
=== Default for LDAP Connections Requires Strong Authentication (updating from <=4.4.0, <=4.3.6 or <=4.2.9) ===
+
=== ID Mapping Configuration Verification ===
  
''The following information might be relevant for you, if you're updating to a later version than mentioned above and have external applications connected over LDAP to your Active Directory:''
+
'''4.6.0 or later'''
  
The security updates 4.4.1, 4.3.7 and 4.2.10 introduced a new smb.conf option for the Active Directory LDAP server to enforce strong authentication. The default of this option ("ldap server require strong auth = yes") allows only simple binds over TLS encrypted connections. In consequence external applications that connect to Active Directory with LDAP can't establish a connection if they don't use or support TLS encrypted connections.
+
Previously, Samba did not verified the ID mapping configuration in the <code>smb.conf</code> file on a domain member. Thus, users could set an incorrect ID mapping configuration, such as overlapping ID ranges or incorrect back ends for the default domain. Consequently, the <code>winbindd</code> service started and ID mapping failed or did not work as expected. The <code>testparm</code> utility has been enhanced and now reports incorrect ID mapping configurations. For example:
  
For further information, see the [https://www.samba.org/samba/history/samba-4.4.1.html 4.4.1], [https://www.samba.org/samba/history/samba-4.3.7.html 4.3.7], or the [https://www.samba.org/samba/history/samba-4.2.10.html 4.2.10] release notes.
+
ERROR: The idmap range for the domain * (tdb) overlaps with the range of SAMDOM (ad)!
  
 +
ERROR: Do not use the 'ad' backend as the default idmap backend!
  
 +
Additionally, when using an incorrect ID mapping configuration, the <code>winbindd</code> service now fails to start and an error message is logged. For example:
  
=== AD database cleanup of deleted LDAP DNS entries (updating from <= 4.1.11) ===
+
[2017/03/01 12:00:00.000000,  0, pid=980] ../source3/winbindd/winbindd.c:1705(main)
 +
  main: FATAL: Invalid idmap backend ad configured as the default backend!
  
Previous versions of Samba DC's contained a bug, that may lead to many deleted LDAP objects for removed DNS entries (partial fix for bug [https://bugzilla.samba.org/show_bug.cgi?id=10749 #10749]).
+
Using Samba 4.6.0 and later, users are no longer able to use incorrect ID mapping configurations.
  
When the first DC with a version newer than 4.1.11 is started, these deleted objects are removed. Depending on the amount, this may result in slow performance until all the deleted objects from the previous version are removed.
+
For further details, supported back ends on a domain member, and their configuration, see:
 +
* [[Identity Mapping Back Ends]]
 +
* the <code>IDENTITY MAPPING CONSIDERATIONS</code> section in the <code>smb.conf(5)</code> man page
  
  
  
=== Wrong TLS .pem file permissions (updating from <= 4.0.11 or 4.1.1) ===
+
=== The <code>ad</code> ID Mapping Back End Now Supports Enabling RFC2307 or Template Mode Per-domain ===
  
* Remove TLS .pem files, because they were exposed by insecure permissions. They are re-created with correct permissions during the next Samba startup
+
'''4.6.0 or later'''
# rm /usr/local/samba/private/tls/*.pem
 
  
 +
Previously, when the <code>winbind nss info</code> parameter was set to <code>rfc2307</code>, the Samba <code>ad</code> ID mapping back end retrieved shell and home directory settings for all Active Directory (AD) domains from AD. In Samba 4.6.0, the new <code>idmap config ''domain_name'':unix_nss_info</code> parameter has been added. This parameter enables the administrator to set on a per-AD domain basis if the shell and home directory settings of users should be retrieved from AD or if the template settings, set in the <code>template shell</code> and <code>template homedir</code> parameters are applied.
  
 +
The new <code>idmap config ''domain_name'':unix_nss_info</code> parameter has a higher priority than the global <code>winbind nss info = rfc2307</code> setting. Therefore, using the <code>idmap config ''domain_name'':unix_nss_info = no</code> default setting for an AD domain, the shell and home directory are no longer retrieved from AD and the values set in the <code>template shell</code> and <code>template homedir</code> parameters are applied. To re-enable retrieving the values from AD for a domain, set in the <code>[global]</code>section in your <code>smb.conf</code> file:
  
=== Fixing dynamic DNS update problems (updating from < 4.0.7) ===
+
idmap config ''domain_name'':unix_nss_info = yes
  
See [[Fix_DNS_dynamic_updates_in_Samba_versions_prior_4.0.7|Fix DNS dynamic updates in Samba versions prior 4.0.7]] for details.
+
For details and an example how to set up, see [[Idmap_config_ad#Configuring_the_ad_Back_End|idmap config ad - Configuring the ad Back End]].

Latest revision as of 03:38, 1 August 2019

Introduction

The following documentation describes the process of updating Samba to a newer version.

If you want to migrate a Samba NT4 domain to Samba Active Directory (AD), see Migrating a Samba NT4 Domain to Samba AD (Classic Upgrade).



Misconceptions About Samba 4

The Active Directory (AD) Domain Controller (DC) support is one of the enhancements introduced in Samba 4.0. However all newer versions include the features of previous versions - including the NT4-style (classic) domain support. This means you can update a Samba 3.x NT4-style primary domain controller (PDC) to a recent version, as you previously updated, for example from 3.4.x to 3.5.x. There is no need to migrate an NT4-style domain to an AD.

Additionally, all recent versions continue to support setting up a new NT4-style PDC. The AD support in Samba 4.0 and later is optional and does not replace any of the PDC features. The Samba team understand the difficulty presented by existing LDAP structures. For that reason, there is no plan to remove the classic PDC support. Additionally we continue testing the PDC support in our continuous integration system.



The Update Process

Run the following steps, whether you are updating a Samba Active Directory (AD) domain controller (DC), a Samba NT4-style PDC, a Samba domain member, or a standalone installation:

  • Stop all Samba services.
  • Create a backup.
  • Read the release notes of skipped versions. They contain important information, such as new features, changed parameter, and bug fixes. In case you switch to new major release, read the release notes of the initial version (x.y.0) and the ones from minor versions up to the new version you will update to. For example, if you update from 4.4.4 to 4.6.2, read the 4.5.0, 4.6.0, 4.6.1, and 4.6.2 release notes.
  • Install the latest version over your existing one:
  • If you compile Samba from the sources, use the same configure options as used for your previous version. For more information, see Build Samba From the Sources.
  • If you update using packages, read the distribution documentation for information how to update.
  • Start Samba.
Start the same daemons as on your previous version:
  • On Samba AD DCs: samba
  • On Samba NT4-style PDC/BDCs: smbd, nmbd
  • On Samba domain members: smbd, nmbd (winbind, if used)
  • On Samba standalone hosts: smbd
  • Check your Samba log files for errors.
  • Test your updated installation.


Upgrading Active Directory Domain Controllers

Upgrading your AD DCs can introduce additional complications, due to things like database compatibility and managing FSMO roles. We recommend that you:


Notable Enhancements and Changes

If you are updating Samba, always read the release notes of all versions between the previous and the one you are updating to. They contain important and additional information on new features, changed parameter options, and so on.

This section provides an overview about important changes that require your attention to fix problems of previous versions, avoid a negative performance impact, and so on.


Changes Affecting All Samba Installation Modes

File Execution Permissions

4.0.0 and later

Previously, Samba did not check the execution bit of files. As a consequence, users could execute files, such as *.exe and *.bat, on a share, if the x-bit was not set. Samba has been enhanced and now denies to execute a file if the x-bit is not set. In situations, such as when upgrading from a previous version, your executable files can be missing the x-bit. As a workaround, you can enable the old behaviour, if you set the following parameter for individual shares or in the [global] section:

acl allow execute always = yes


Samba Active Directory Domain Controllers

The ntvfs File Server Back End Has Been Disabled

4.5.0 and later

Previously, Samba enabled users to provision a domain controller (DC) using the ntvfs file server back end. This back end was never supported, and thus the ntvfs feature is no longer build by default in Samba 4.5.0. Consequently, starting the samba service on a DC using the ntvfs back end failed after the update and the following error is logged:

[2016/09/01 08:00:00.000000,  0, pid=995] ../source4/smbd/service.c:98(server_service_startup)
  Failed to start service 'smb' - NT_STATUS_INVALID_SYSTEM_SERVICE
[2016/09/01 08:00:00.000000,  0, pid=995] ../lib/util/become_daemon.c:111(exit_daemon)
  STATUS=daemon failed to start: Samba failed to start services, error code -1073741796

To fix the problem, migrate the file server back end on your DC to the supported s3fs back end. For details, see Migrating the ntvfs File Server Back End to s3fs.


Fixing replPropertyMetaData Attributes

4.5.0 and later

Samba versions prior to 4.5.0 stored the replPropertyMetaData attribute incorrectly. As a consequence, administrators could experience, for example, renaming conflicts. The problem has been fixed in 4.5.0 and later versions and Samba now stores the attribute correctly. The samba-tool utility has been enhanced to detect incorrectly stored replPropertyMetaData attributes:

# samba-tool dbcheck --cross-ncs

To fix the attributes, run:

# samba-tool dbcheck --cross-ncs --fix --yes
...
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000003
CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000000
ERROR: unsorted attributeID values in replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com

Fix replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com by sorting the attribute list? [YES]
Fixed attribute 'replPropertyMetaData' of 'CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com'

Note that the --yes parameter automatically fixes all problems found and not only the replPropertyMetaData attributes!

Run the check and fix operation on all Samba Domain Controllers (DC), because replPropertyMetaData is a non-replicated attribute and modifications are not replicated to other DCs.

For more information, see the Samba AD DC database check section.

Failure To Access Shares on Domain Controllers If idmap config Parameters Set in the smb.conf File

4.4.6 or later

The winbindd service on a Samba Active Directory (AD) domain controller (DC) automatically uses the IDs set in the Active Directory uidNumber and gidNumber attributes of user accounts and groups. If the attributes are not set, Samba generates IDs locally on the DC and stores them in the idmap.ldb database. Thus, on a Samba AD DC, idmap config parameters set in the smb.conf file were ignored. Due to a bug in Samba 4.4.6 and later, the parameters are no longer ignored and clients fail to connect to shares on the DC. To fix the problem:

  • Remove all idmap config parameters in the smb.conf file on DCs.
  • Restart the samba service.
  • Restart the clients.

As a result, clients now correctly connect to shares on the DC.


New Default for LDAP Connections Requires Strong Authentication

4.4.1 or later / 4.3.7 or later / 4.2.10 or later

The security updates 4.4.1, 4.3.7 and 4.2.10 introduced a new smb.conf option for the Active Directory (AD) LDAP server to enforce strong authentication. The default for this new option ldap server require strong auth is yes and allows only simple binds over TLS encrypted connections. In consequence, external applications that connect to AD using LDAP, cannot establish a connection if they do not use or support TLS encrypted connections.

Applications connecting to Samba AD using the LDAP protocol without encryption, will display the error message:

ldap_bind: Strong(er) authentication required (8)
       additional info: BindSimple: Transport encryption required.

For further information, see the 4.4.1, 4.3.7, or the 4.2.10 release notes.


AD Database Cleanup of Deleted LDAP DNS Entries

4.1.12 or later

Previously, Samba incorrectly created deleted Active Directory (AD) objects for removed DNS entries. The problem has been fixed. If you start the first Domain Controller (DC) with a fixed Samba version, all deleted objects are removed. As a result, this can result in a slow performance until the deleted objects are removed.


Incorrect TLS File Permissions

4.1.2 or later / 4.0.12 or later

Previously, Samba created the *.pem files used for LDAP TLS encryptions with insecure permissions. To avoid insecure connections, delete the files on all domain controllers (DC):

# rm /usr/local/samba/private/tls/*.pem

Restart Samba after you deleted the files to automatically re-create the new certificates.


Fixing Dynamic DNS Update Problems

4.0.7 or later

See Fix DNS dynamic updates in Samba versions prior 4.0.7 for details.


Fixing Incorrect Sysvol and Directory ACLs

When updating from early 4.0.x versions, 4.0 beta and 4.0 release candidates.

  • To reset wrong Sysvol ACLs, run:
# samba-tool ntacl sysvolreset
  • To reset all well known ACLs in the directory, run:
# samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
  • To fix errors in the Active Directory (AD) database, run:
# samba-tool dbcheck --cross-ncs --fix

Samba Domain Members

ID Mapping Configuration Verification

4.6.0 or later

Previously, Samba did not verified the ID mapping configuration in the smb.conf file on a domain member. Thus, users could set an incorrect ID mapping configuration, such as overlapping ID ranges or incorrect back ends for the default domain. Consequently, the winbindd service started and ID mapping failed or did not work as expected. The testparm utility has been enhanced and now reports incorrect ID mapping configurations. For example:

ERROR: The idmap range for the domain * (tdb) overlaps with the range of SAMDOM (ad)!
ERROR: Do not use the 'ad' backend as the default idmap backend!

Additionally, when using an incorrect ID mapping configuration, the winbindd service now fails to start and an error message is logged. For example:

[2017/03/01 12:00:00.000000,  0, pid=980] ../source3/winbindd/winbindd.c:1705(main)
  main: FATAL: Invalid idmap backend ad configured as the default backend!

Using Samba 4.6.0 and later, users are no longer able to use incorrect ID mapping configurations.

For further details, supported back ends on a domain member, and their configuration, see:


The ad ID Mapping Back End Now Supports Enabling RFC2307 or Template Mode Per-domain

4.6.0 or later

Previously, when the winbind nss info parameter was set to rfc2307, the Samba ad ID mapping back end retrieved shell and home directory settings for all Active Directory (AD) domains from AD. In Samba 4.6.0, the new idmap config domain_name:unix_nss_info parameter has been added. This parameter enables the administrator to set on a per-AD domain basis if the shell and home directory settings of users should be retrieved from AD or if the template settings, set in the template shell and template homedir parameters are applied.

The new idmap config domain_name:unix_nss_info parameter has a higher priority than the global winbind nss info = rfc2307 setting. Therefore, using the idmap config domain_name:unix_nss_info = no default setting for an AD domain, the shell and home directory are no longer retrieved from AD and the values set in the template shell and template homedir parameters are applied. To re-enable retrieving the values from AD for a domain, set in the [global]section in your smb.conf file:

idmap config domain_name:unix_nss_info = yes

For details and an example how to set up, see idmap config ad - Configuring the ad Back End.