Difference between revisions of "Updating Samba"

m (Updated link)
m (/* grammar)
Line 14: Line 14:
 
}}
 
}}
  
The Active Directory (AD) Domain Controller (DC) support is one of the enhancements 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 PDC to a recent version, like you updated in the past - for example from 3.4.x to 3.5.x. There is no need to migrate an NT4-style domain to an AD.
+
The Active Directory (AD) Domain Controller (DC) support is one of the enhancements 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 PDC to a recent version, just as you updated in the past - for example from 3.4.x to 3.5.x. There is no requirement 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 for the PDC feature. 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.
+
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.
  
  
Line 26: Line 26:
 
If you are updating multiple Samba Active Directory (AD) Domain Controllers (DC), the recommended order is:
 
If you are updating multiple Samba Active Directory (AD) Domain Controllers (DC), the recommended order is:
  
* Update one Samba AD DC that is is not holding any flexible single master operations (FSMO) role.
+
* Update one Samba AD DC that does not hold any flexible single master operations (FSMO) role.
  
 
* Start Samba on the updated DC.
 
* Start Samba on the updated DC.
Line 43: Line 43:
 
= The Update Process =
 
= The Update Process =
  
Run the following steps, regardless if you are updating a Samba Active Directory (AD) domain controller (DC), a Samba NT4-style PDC, a Samba domain member, or a standalone installation:
+
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.
 
* Stop all Samba services.
Line 53: Line 53:
 
* Install the latest version over your existing one:
 
* Install the latest version over your existing one:
  
:* If you compile Samba from the sources, use the same <code>configure</code> options like 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 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.
 
:* If you update using packages, read the distribution documentation for information how to update.
  
 
* Start Samba.
 
* Start Samba.
: Start the same daemons like for your previous version:
+
: Start the same daemons as your previous version:
 
:* On Samba AD DCs: <code>samba</code>
 
:* On Samba AD DCs: <code>samba</code>
 
:* On Samba NT4-style PDC/BDCs: <code>smbd</code>, <code>nmbd</code>
 
:* On Samba NT4-style PDC/BDCs: <code>smbd</code>, <code>nmbd</code>
Line 64: Line 64:
 
:* On Samba standalone hosts: <code>smbd</code>
 
:* On Samba standalone hosts: <code>smbd</code>
  
* Only on Samba AD DCs: Run the [[#Samba_AD_DC_Database_Check|Samba AD DC database check]].
+
* On Samba AD DCs only: Run the [[#Samba_AD_DC_Database_Check|Samba AD DC database check]].
  
 
* Check your Samba log files for errors.
 
* Check your Samba log files for errors.
Line 108: Line 108:
 
'''Updating to 4.0.0 and later'''
 
'''Updating to 4.0.0 and later'''
  
Previously, Samba did not checked the execution bit of files. As a consequence, users could execute files like *.exe, *.bat, etc. on a share, even 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, like when upgrading from a previous version, your executable files can miss the x-bit. As a workaround, you can enable the old behavior, if you set the following parameter for individual shares or in the [global] section:
+
Previously, Samba did not checked the execution bit of files. As a consequence, users could execute files like *.exe, *.bat, etc. on a share, even 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 = true
 
  acl allow execute always = true
Line 120: Line 120:
 
'''Updating to 4.5.0 and later'''
 
'''Updating to 4.5.0 and later'''
  
Samba versions prior 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 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
 
  # samba-tool dbcheck --cross-ncs
Line 149: Line 149:
 
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.
 
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, are displaying error messages like:
+
Applications connecting to Samba AD using the LDAP protocol without encryption, will display the error message:
  
 
  ldap_bind: Strong(er) authentication required (8)
 
  ldap_bind: Strong(er) authentication required (8)
Line 162: Line 162:
 
'''Updating to 4.1.12 or later'''
 
'''Updating to 4.1.12 or later'''
  
Previously, Samba incorrectly created many 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.
+
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.
  
  
Line 198: Line 198:
 
* To fix errors in the Active Directory (AD) database, run:
 
* To fix errors in the Active Directory (AD) database, run:
 
  # samba-tool dbcheck --cross-ncs --fix
 
  # samba-tool dbcheck --cross-ncs --fix
 +
  
  

Revision as of 19:14, 19 November 2016

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


Common Misconceptions About Samba 4

The Active Directory (AD) Domain Controller (DC) support is one of the enhancements 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 PDC to a recent version, just as you updated in the past - for example from 3.4.x to 3.5.x. There is no requirement 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.



Updating Multiple Samba Domain Controllers

If you are updating multiple Samba Active Directory (AD) Domain Controllers (DC), the recommended order is:

  • Update one Samba AD DC that does not hold any flexible single master operations (FSMO) role.
  • Start Samba on the updated DC.
  • Verify that the directory replication between all DCs is working correctly:
# samba-tool drs showrepl
  • Test the installation to ensure that the new version works correctly.
  • Upgrade all other Samba DCs one at a time and always verify that the replication is working correctly.



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 all release notes of versions since the one you are updating from. They contain important information on new features, changed parameter options, and so on.
  • 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 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.



Samba AD DC Database Check

The samba-tool utility enables you to detect and fix problems in the Samba Active Directory (AD) database. For example, if a previous Samba version stored an attribute incorrectly and the updated version fixes the problem. You must run the check and fix command on every Samba AD DC locally, because some fixes apply to non-replicated attributes and modifications are not replicated to other DCs.

To check the AD database, run:

# samba-tool dbcheck --cross-ncs

To fix reported errors, run:

# samba-tool dbcheck --cross-ncs --fix

If you pass the --yes parameter to the command, all questions are automatically answered with yes. Note that if you omit the --yes parameter, the database check executes three fsync() calls for each object. This can result result in a longer run duration. For example, passing the --yes parameter to the command fixed 3500 objects in 10 seconds in our test environment. Without this parameter, the command required 4:50 minutes for the same operation.

After a repair, re-check the database to verify a successful operation.



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.


All Samba Installations

File Execution Permissions

Updating to 4.0.0 and later

Previously, Samba did not checked the execution bit of files. As a consequence, users could execute files like *.exe, *.bat, etc. on a share, even 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 = true


Samba Active Directory Domain Controllers

Fixing replPropertyMetaData Attributes

Updating to 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.


Default for LDAP Connections Requires Strong Authentication

Updating to 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

Updating to 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

Updating to 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

Updating to 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

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

No remarkable important changes.