View source for Migration from Samba 3 to Samba 4

{{Version|UCS=3.0}}
{{Version|UCS=3.1}}
{{Version|UCS=3.2}}

For UCS@school environments, please refer to the article: [[UCS@school Samba 3 to Samba 4 Migration]]

To update a Samba 3/NT4 domain to an Samba 4/AD domain, there are two options described below. The first update scenario is suitable for larger domains, where an in place switch of all productive DCs in a single maintenance window is not feasable. This update szenario offers a stepwise transition from the existing Samba 3/NT4 domain to the new Samba 4/AD domain, where the pace of transition can be chosen by the resources available. The second update scenario on the other hand is an option for smaller domains, where an in place switch of all productive DCs is possible in a single maintenance window.

All steps described here schould be tested first in a non-productive snapshot of the main productive environment. A good starting point for creating a virtualised copy of the productive systems might be [[Migrating_a_native_UCS_installation_to_UVMM#Migration_by_copying_the_core_files|this Howto article]].

= Preparations for the update to Samba 4 =

{{Logo Samba}}

* Make sure you know about the underlying conceptual differences between a Samba3/NT Domain and Samba4/Active Directory. We strongly recommend to review the existing setup to meet the changed requirements. If you are unsure about designing an Active Directory Domain please read the Microsoft documentation carefully or consult Univention Professional Services.

* All steps schould be tested first in a non-productive snapshot of the main productive environment.

* Before starting the update process, as usual, make sure up-to-date backups of all DCs are available. This is especially important for the in place update of scenario 2.

* Before starting the update process, it is important to check the consistency of the LDAP data. As a starting point the following script should be run to ensure that all users are listed as members of their primary group:

 /usr/share/univention-directory-manager-tools/proof_uniqueMembers

* Samba 4 does not evaluate the per-server UCR setting samba/profilepath. As a consequence serverside profiles are not used any longer by default. Instead Samba 4 uses the per-user LDAP attribute ''sambaProfilePath'', which can be set in the Univention Directory Manager in the field ''Windows profile directory'' in section ''Windows'' on the ''Account'' tab. Its value can be set via multiedit or via user-template. The directory name is an UNC-path and can contain Windows environment variables, e.g.

  \\ucsservername\%UserName%\profile

* Please ensure that the length of the host names of your Samba servers does not exceed 13 characters and that none of the host names is identical to the NETBIOS domain name

= Update Scenario 1 - Stepwise migration from Samba 3/NT4 to the Samba 4/AD domain =
In this scenario the new Samba 4/AD domain is build up in a step-by-step fashion, with both domains, the Samba 3/NT4 and the Samba 4/AD domain running in parallel for the time of transition. The common ID management is provided by the UCS directory service, holding all the present user, group, machine and share definitions. The Samba 3 and Samba 4 services are configured to serve different Netbios names and domain SIDs. Each of the UCS domain controllers, member servers and Microsoft Windows clients is joined either to the Samba 3/NT4 domain exclusively or to the Samba 4/AD domain. After all client systems have been transferred to the Samba 4/AD domain, the remaining Samba 3/NT4 domain controllers can either be transferred too, or deactivated if superceeded.

== Preparation of the UCS 3.x domain ==
* Update of the entire UCS domain to at least UCS 3.0. It is recommended to perform the migration with UCS 3.2.
* Make sure that the existing UCS Kerberos realm (UCR Variable kerberos/realm) matches the DNS domainname of the UCS domain. This is mandatory.
* The UCR variable ''directory/manager/samba3/legacy'' must be set to '''yes''' on all UCS domaincontrollers (DC Master, DC Backup, DC Slave), regardless, even if they do not offer Samba 3 services.
* The UCR variable ''connector/s4/mapping/sid must'' be set to '''false''' on each UCS server before the installation of the Samba 4 Service.
* It might be a good idea to setup a UCR-policy for these UCR-Variables in the Univention Directory Manager (UDM) and assign it to the appropriate container in the UCS directory.
* Do not install Samba 4 DCs into the existing UCS Samba 3 windows domain.

== Installation of the first Samba 4 DC ==
The following steps create the new Samba 4/AD domain:

* The first UCS DC with Samba 4 can be installed after all existing systems have been updated properly to UCS 3.0 or later. It is recommended to perform the migration with UCS 3.2. 
* A new Samba 4 DC must be installed with server role "DC Backup".
** The new Samba 4 DC must use a windows domain name different from the existing ''windows/domain'' of the UCS Samba 3 windows domain.
** Activate Samba 4 AD Services in the software selection.
*** In the UCS installer make sure to '''deselect''' the automatic join at the end of installation. At the end of the installation process a warning will be displayed because the machine was not joined yet. This will be done in the next step.
** On the successfully installed DC Backup run the following commands:
  ucr set connector/s4/mapping/sid=false \
  directory/manager/samba3/legacy=yes \
  samba4/ignore/mixsetup=yes
  univention-join
  /etc/init.d/univention-s4-connector restart
* The maximum password age setting in Samba4 should be set manually before the migration of the other domain controllers. E.g. the following command sets the maximum password age to zero:

 samba-tool domain passwordsettings set --max-pwd-age 0

== Installation of additional Samba 4 DCs ==
* After the first UCS Samba 4 DC has been installed, additional Samba 4 Servers can be installed into the new Samba 4/AD domain. These can also be UCS DC Slaves.
** The UCS Samba 4 DCs must use the ''windows/domain'' name of the Samba 4/AD domain.
** Activate Samba 4 AD Services in the software selection.
*** In the UCS installer make sure to '''deselect''' the automatic join at the end of installation. At the end of the installation process a warning will be displayed because the machine was not joined yet. This will be done in the next step.
** On the successfully installed UCS DC run the following commands:
  ucr set connector/s4/mapping/sid=false \
  directory/manager/samba3/legacy=yes \
  samba4/ignore/mixsetup=yes
  univention-join

== Stepwise Migration of Microsoft Windows Clients to the Samba 4/AD domain ==
* By following the steps above the new Samba 4/AD domain is now running in parallel alongside the Samba 3/NT4 domain.
* At this point all UCS users will still be able to login to the UCS Samba 3 domain.
* Now Microsoft Windows clients can be joined one by one into the new Samba 4/AD domain.
* To make sure the setup procedure worked as expected, please verify that existing UCS users are able to log on to a newly joined Microsoft Windows client using their current passwords.
* The users will be able to access the file and print services of the UCS Samba 3 domain controllers transparently.
** If there are any Samba 3 fileservices in the UCS domain hosted on UCS member servers, transparent authentication to them can be setup by adding the following configuration fragment into the file /etc/samba/local.conf on those fileservers:
<pre>## /etc/samba/local.conf
[global]
   map untrusted to domain = yes</pre>
* If transparent authentication still does not work, there are two options:
** Depending on the client settings it might be necessary to adjust the Group Policy  "''Network security: LAN Manager authentication level''" to "''Send LM & NTLM responses''".
** Alternatively the behavior of the UCS member server can be adjusted by setting the UCR Variable ''samba/memberserver/passdb/ldap'' to ''yes'' and restarting /etc/init.d/samba.

== Stepwise Migration of UCS member servers to the Samba 4/AD domain ==
The UCS member servers can be joined to the Samba 4/AD domain by setting the UCR variable ''windows/domain'' to the new ''windows/domain'' name of the Samba 4/AD domain and running ''univention-join''.

== Stepwise Migration of the UCS Samba 3 DCs to the Samba 4/AD domain ==
After all Microsoft Windows clients have been joined into the new Samba 4/AD domain, the remaining Samba 3 DC services can be uninstalled on UCS Servers. This should be done in a stepwise fashion, starting with Samba 3 BDCs and finishing with the UCS Samba 3 PDC. Proceed with the following steps on each UCS server offering Samba 3 DC services:

* purge the Samba 3 packages by running the command
  apt-get remove --purge samba winbind
* In Univention Config Registry set windows/domain to the name of the new Samba 4/AD domain.
* optionally install the ''univention-samba4'' package by running the following commands
  ucr set samba4/ignore/mixsetup=yes \
          samba4/ntacl/backend=native \
          samba/debug/level=1
  univention-install univention-samba4
  univention-run-join-scripts --ask-pass

== Deactivation of the Samba 3/NT4 domain ==
After all Samba 3 services have been removed from the UCS domain, the Samba 3 domain can be disposed of by the following two steps. It is advisable to do this step in a mainenance window to avoid disturbance of productive systems.

* The Samba 3 SIDs in the UCS OpenLDAP directory can be replaced by the Samba 4 SIDs with the tool <pre>/usr/share/univention-samba4/scripts/migrate-sid.py</pre>
* The ''migrate-sid.py'' tool should be startet on the UCS DC Master or on a UCS DC Backup, e.g. the DC Backup providing the ''S4 Connector'' service.
* After the Samba 4 SIDs are active, the UCR variable ''directory/manager/samba3/legacy'' should be unset on each UCS Domaincontroller (DC Master, DC Backup, DC Slave).
* Likewise the UCR variable ''connector/s4/mapping/sid'' must be unset on each UCS system offering Samba 4 Services.
* If a UCR-policy was set up for these UCR-Variables in the Univention Directory Manager (UDM) and assigned to a container in the UCS directory, this UCR-policy must be removed.
* After unsetting these UCR variables, the Univention S4 Connector needs to be restartet by running the following command on the System that provides the ''S4 Connector'' service :
 /etc/init.d/univention-s4-connector restart
* In case of doubt run the univention-s4-connector restart on all UCS DC Master and UCS DC Backup systems.
* Check the UCR variable ''windows/domain'' on all UCS systems and make sure to replace the name of the Samba 3 domain by the name of the new Samba 4/AD domain.

= Update Scenario 2 - In place upgrade of the Samba 3/NT4 to a Samba 4/AD domain =

It is advisable to do the in place upgrade of the Samba 3/NT4 to a Samba 4/AD domain in a mainenance window to avoid disturbance of productive systems.

== Preparation of the UCS domain ==
* Update of the entire UCS domain to at least UCS 3.0. It is recommended to perform the migration with UCS 3.2.
* Ensure that all UCS updates are installed.
* Make sure that the existing UCS Kerberos realm (UCR Variable kerberos/realm) matches the DNS domainname of the UCS domain. This is mandatory.
* Beware that all Samba 3 domain controllers have to be updated to Samba 4 in this scenario. Unexpected results may occur while any Samba 3 domain controllers are still active.

== Migration of the first Samba 3 DC ==
The following steps migrate the first DC from Samba 3 to Samba 4. This is the only first step to turn the Samba 3/NT4 domain into a Samba 4/AD domain.

* Before the first UCS DC can be upgraded to Samba 4, all existing systems must be updated properly at least to UCS 3.0.
* The first UCS 3.x Samba 3 DC that should be migrated should have UCS server role ''Master'' as it will be the System that will provide the ''S4 Connector'' service.
* If the UCS domain was installed initially with an UCS version before UCS 3.2, the following UCR variable needs to be set
 ucr set connector/s4/mapping/group/grouptype=false
* If the UCS Master does not offer Samba 3 DC services, a system of the UCS server role ''Backup'' should be selected instead. In case no UCS Backup server has been installed yet with Samba 3, it needs to be installed at this point.
* If the Master
* The Upgrade can be initiated by the following commands:
  ucr set samba4/ignore/mixsetup=yes \
          samba4/ntacl/backend=native \
          samba/debug/level=1
  univention-install univention-s4-connector
* Due to the current known {{Bug|29772}} in the conversion of the maximum password age in UCS 3.1-0, the maximum password age setting in Samba4 should be set manually before the migration of the other domain controllers. E.g. the following command sets the maximum password age to zero:

 samba-tool domain passwordsettings set --max-pwd-age 0
* The Samba 3 to Samba 4 in-place migration script migrates users, groups and computers to the default locations in the Samba 4 directory. In case additional containers are present in the UCS LDAP directory, e.g. orginizational units (OU), it is necessary to run the following script as the next step, to synchronize the object positions in the Samba 4 directory to match the structure in the UCS LDAP directory. It is recommended to run first the script with the option ''--dry-run'' to see what steps would be taken:
 /usr/share/univention-s4-connector/univention-s4-position-sync --dry-run
:If this looks reasonable, the command shoud be run again without this option:
 /usr/share/univention-s4-connector/univention-s4-position-sync
* To complete the setup of dynamic DNS updates, univention-run-join-scripts needs to be run:
 univention-run-join-scripts
* Finally it is recomended to reset the sysvol-ACLs to the recommended values by running
 samba-tool ntacl sysvolreset

== Migration of all other Samba 3 DCs ==
* After the first UCS DC has been upgraded into a Samba 4 DC, all other UCS  Samba 3 Servers must be upgraded in turn, starting with UCS DC Backup systems and finishing with UCS DC Slave systems.
* On UCS DC Backup systems the upgrade can be initiated by the following commands:
  ucr set samba4/ignore/mixsetup=yes \
          samba4/ntacl/backend=native \
          samba/debug/level=1
  univention-install univention-s4-connector
  univention-run-join-scripts --ask-pass
* The actual ''S4 Connector'' service will only be started on the first UCS Samba 4 DC.
* On UCS DC Slave systems the upgrade can be initiated by the following commands:
  ucr set samba4/ignore/mixsetup=yes \
          samba4/ntacl/backend=native \
          samba/debug/level=1
  univention-install univention-samba4
  univention-run-join-scripts --ask-pass
* Note that the package univention-s4-connector is not installed on UCS DC Slaves.
* After all UCS Samba 3 DCs have been upgraded to Samba 4 DCs make sure the procedure worked as expected, e.g. by verifying that existing UCS users are able to log on to the Microsoft Windows clients.

== Migration of the UCS member servers ==
On UCS member servers the mode of domain membership needs to be reconfigured from NT4-domain membership to AD-domain membership. This can be achieved simply by setting an UCR variable and joining the systems again, i.e. by running
  ucr set samba4/ntacl/backend=native
  univention-join
and rebooting the machine after the join process completed successfully.

= Post-Migration Tasks =
* Netlogon scripts are not migrated automatically. They should be checked and can copied to the new location. In univention-samba3 they are stored below ''/var/lib/samba/netlogon'', univention-samba4 expects them below ''/var/lib/samba/sysvol/$domainname/scripts''. Logon scripts can also be configured via GPO.
* The Samba 4 domain password policies can be looked up running
 samba-tool domain passwordsettings show
* The Samba 4 domain password policies can be adjusted manually to match the values in the UCS directory. As an example, the password expiry can be disabled with the special value 0:
 samba-tool domain passwordsettings set --max-pwd-age=0
* After all Samba 3 DCs have been migrated to Samba 4, the service "Samba 3" schould be removed from the Samba 4 DCs. The following command line may be used on a UCS Master to identify the DCs that are still marked as offering "Samba 3", while they actually already serving "Samba 4":
 for role in master backup slave; do \
     udm computers/domaincontroller_$role list \
         --filter '(&(service=Samba 4)(service=Samba 3))' \
     | grep ^DN:; \
 done

[[Category:Samba 4]]
[[Category:EN]]