View source for Best Practice Samba 4 Migration

{{Version|UCS=3.0}}

This Best Practice Guide is trying to support you while migrating from UCS 2.4 or UCS 3 with Samba 3 to UCS 3 with Samba 4. It is based on the experiences of Univention's Professional-Service team. Please do not assume that this guide is fit for or covers any situation or can replace a customized update plan.

= Status Review =
== Domain Review ==
Starting point for the preparations is a review of your domain. Crucial for a successful migration are the correct settings and workings of Kerberos and DNS as well as a clean and organized LDAP.

=== Kerberos Realm, Samba and DNS Domain ===
To migrate to Samba 4 your Kerberos and DNS Domain need to be equal. Meaning that a DNS Domain 'my.example.com.' needs 'MY.EXAMPLE.COM' as its Kerberos Realm and 'MY' as the Samba Domain. Your DNS Domain needs to consist of at least two parts, so 'my.domain.' is ok while my. is not. Please note that you can ignore the tailing dot of the DNS Domain in all Univention tools.

If your DNS Domain, your Samba Domain and your Kerberos Realm do not agree you can change the DNS Domain and/or Samba Domain using
 univention-system-setup-base
Unfortunately there is no easy way to change the Kerberos Realm. Univention is happy to assist you with a customized solution in case you want to change your Kerberos Realm.

=== Samba SIDs ===
After ensuring the basing settings one needs to have a look into the Samba SIDs of your Groups. If you migrated from a different Samba 3 installation, a Microsoft Windows NT Domain, have your UCS System since pre 2.0 or seperated Windows and LDAP Administration it is likely that one or more of the following mappings between Group and Samba RID do not agree. To show the Samba RID issue the following command, replacing <name> with the name from the table below:
<pre>
 udm groups/group list --filter 'cn=<name>'
</pre>
{| class="wikitable"
!Name
!sambaRID
|-
|Domain Admins
|512
|-
|Domain Users
|513
|-
|Domain Guests
|514
|-
|Administrators
|544
|-
|Users
|545
|-
|Guests
|546
|-
|Power Users
|547
|-
|Account Operators
|548
|-
|System Operators
|549
|-
|Printer-Admins
|550
|-
|Backup Operators
|551
|-
|Replicators
|552
|}
It is crucial that the first 3 are present. The later one may miss. However if present their mapping has to match the one given in the table. If your mapping does not agree, do not update. Either consider fixing them or migrating to a fresh installation. Please contact Uninvention if you need assistance in fixing the mapping.

=== root user and root group ===
It is in general inadvisable to have users or groups with the name root or the id number 0 in the LDAP. If you nevertheless have one it is necessary to remove them before migrating to Samba 4.

== System Review ==
For the System Review it is good practice to list all servers with their IPs, operating system, name and functions. You might want to do the same for your clients or group your clients by functions e.g. UCD 3.1 Clients with Accounting Software and Windows XP with HR Applications.

=== UCS Version ===
When starting from a pre UCS 3 installation you should not start reviewing before having updated your system to UCS 2.4-4-7. The most recent version of UCS 3 is advisable if you have already completed the update or are started with a UCS 3 installation.

=== Windows Versions ===
Windows Version older then Windows 2000 and Windows Server 2000 are not participating in Kerberos and should be replaced. We recomend migrating needed services to UCS Services or at least updating to a recent patchlevel of Windows 7 or Windows Server 2008 R2.

=== CPU and Memmory ===
Samba 4 is moderately demanding on resources. For operating as a Samba 4 Domain Controller, a UCS domain controller Slave should have at least two CPU Cores and two GB of Memory. The domain controller Master and at least one domain controller Backup should feature 4 Cores and 4 GB of Ram. This is necessary to allow the Univention S4 Connector on the domain controller Master to run at a sufficient speed even when frequent password changes and DDNS announcements occur. In case you are running additional services, such as Mail or Terminal Services, on your systems they will need additional Resources.

== Sotware Review ==
Also review the used software. This is true for both your UCS and your Windows Systems. Especially software distributed over multiple systems or software using UCS domain services for their authentication have to be considered.

=== Linux Software ===
If you are using Software on your UCS Servers which is either Kerberized, using LDAP for keeping its data or using its own customized PAM modules for its authentication have to be reviewed for their support of UCS 3 for the client server combinations. It is most likely that the LDAP port has to be changed to 7389 and authenticated LDAP is to be used. Most integration packages will tell you in their release notes if additional steps have to be taken.

=== Windows Software ===
Software running on Windows and relying on distributed authentication, e.g. IIS with Microsoft SQL as their backend, should be checked for their UCS Compatibility. We have a growing list of [[Howtos Samba 4|applications]] known to be working and are happy to include your experience.

= Planning Domain =
If you are updating from a UCS 2.4 domain you already have a topology for your domain in place. When migrating to Samba 4 you should think of where you need Samba 4 domain controllers and about the separation of data and domain services.

== Sites ==
Samba 4/AD inter site replication and logins are distributed over the different domain controllers in a round robin fashion. If you are having distributed branches this means that your login might travel from one end of the world to another unless you are using sites. A Site should therefore be a well connected set of servers and clients like a head branch office. Small branche offices should be connected to bigger ones and share their domain controller. It is planned that UCS 3.0-2 will support site configurations.

== Number of Domain Controller ==
For a Samba 4 deployment you want to keep the number of domain controllers to a reasonable number. For most cases a single DC should be sufficient. To limit the number of replications between the DCs it is also strongly advisable to move File and Print Services to a dedicated Member Server. Please keep in mind that at least for your primary installation a DC Backup with Samba 4 should be used to provide redundancy. 

= Preparing a Test Environment =
After reviewing the domain and planning the update it should be tested in a separate test environment. Apart from your the systems crucial to your business you should also include all servers and sample clients, as well as the crucial software found during the review.

= Testing the Update =
== UCS 3 Update ==
If you are not running an UCS 3 domain the first step is to update all your systems to UCS 3.x-x. Please refer to the update guide, handbook and changelog for detailed instructions. After updating you should test whether all your applications are still operational. If you are planning to split the Update into multiple steps, this would be a save place to stop.

== Salting the Kerberos Keys ==
After the update of all systems it is nesseceary to salt your Kerberos Keys in accordance with the documentation. Simply calling the script <pre>/usr/share/univention-heimdal/salt_krb5Keys</pre>

== Updating Samba ==
For the Samba update please follow your preferred way for the update in our [[Update to UCS 3.0 Samba 4 | update guide]].

During the initial initialization the join script might run into an error condition. If so it will give you advises on how to resolve them before recalling
<pre>
univention-run-join-scripts
</pre>
again.

== Testing your Systems ==
After updating please test the login for both users and Administrators on all operating systems. You should also test changing the password on both UCS and Windows as well as through the UMC.

After you have ensured that you can login to all Systems continue with assuring the functionality of the Operation Critical Software identified during the review phase.

= Productive Update =
Once you have completed all tests and are reasonable sure that all your software will continue to function you can update your system. During the update it is a good idea to test the basic functions like LDAP, DNS and Kerberos after each of the three steps.

If you are doing an in-place-update and if you are doing it outside your normal hours of operation, switch on few Windows clients after the update. This way you can first ensure that everything worked as planned, before facing the challenge to rejoin all your clients in case the update went wrong.

= Post Update Tasks =
Once the update is completed you have to (re)start all your Microsoft Windows Systems to allow them to join the domain. While this will happen for all clients once the work day starts, you might have to schedule it for the Servers.

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