Best Practice Samba 4 Migration
From Univention Wiki
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. It is only meant to complement but not to replace a customized update plan.
- 1 Status Review
- 1.1 Domain Review
- 1.2 System Review
- 1.3 Sotware Review
- 2 Planning Domain
- 3 Preparing a Test Environment
- 4 Testing the Update
- 5 Productive Update
- 6 Post Update Tasks
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.
If your DNS Domain, your Samba Domain and your Kerberos Realm do not match you can change the DNS Domain and/or Samba Domain using
After confirming the base settings the Samba SIDs of your groups should be checked. If you migrated from a different Samba 3 installation, a Microsoft Windows NT Domain, have your UCS system since pre 2.0 or separated 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:
udm groups/group list --filter 'cn=<name>'
Root User and Root Group
Unique Samba Account Names for Users and Groups
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 Microsoft Windows XP with HR Applications.
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.
CPU and Memmory
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 access and LDAP search need to be configured. Most integration packages will tell you in their release notes if additional steps have to be taken.
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 applications known to be working and are happy to include your experience.
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.
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 branch office 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 might want to keep the number of domain controllers at a reasonably low 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
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 the latest UCS 3.x-x release and ensure that the latest errata updates are installed. 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 safe place to stop.
Salting the Kerberos Keys
After the update of all systems to UCS 3 it is nesseceary to salt your Kerberos keys as advised in the release notes. This can be achieved by calling the script
For the Samba update please follow your preferred way for the update in our update guide.
During the initial initialization the join script might run into an error condition. If so it should give you advice on how to resolve them.
To retry the update it may be necessary to ensure that Samba4 has not taken over the standard LDAP port from OpenLDAP yet. The following commands ensure that OpenLDAP runs on the standard port:
/etc/init.d/samba4 stop ucr set slapd/port="389,7389" slapd/port/ldaps="636,7636" /etc/init.d/slapd restart
After checking everything, the update process may be started by running
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.
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 which should be done outside of the regular hours of business operation, switch on a few Micosoft 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.