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 Software Review
- 2 Planning Domain
- 3 Preparing a Test Environment
- 4 Testing the Update
- 5 Productive Update
- 6 Post Update Tasks
Starting point for the preparations is a review of your domain. Crucial for a successful migration are the correct settings and operation of Kerberos and DNS as well as a clean and organized LDAP.
Kerberos Realm 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.
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.
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>'
It is crucial that the first 3 are present. The later one may be missing. 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 Univention if you need assistance in fixing the mapping.
For the users the following mappings between users and SID are needed. Only the Administrator has to be there.
udm users/user list --filter 'uid=<name>'
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.
univention-ldapsearch -LLL uidNumber=0 dn univention-ldapsearch -LLL uid=root dn univention-ldapsearch -LLL cn=root dn
Unique Samba Account Names for Users and Groups
Since the Microsoft Windows security account manager (SAM) and its corresponding Samba implementation treat both users and groups as SAM accounts, it is important that there are no conflicts with respect to the name of these objects. If there are user accounts that have the same name as a group it is necessary to rename one of both to avoid failure during the update process from Samba 3 to Samba 4.
Also take a closer look to reported warnings.
Check for multiple sambaSID
In place migration will be fail, if multiple sambaSID exist. So check for multiple sambaSID with:
univention-ldapsearch -LLL sambaSID dn|grep ^sambaSID|sort|uniq -d
Search the DN for the result(s). Objects below 'cn=idmap,cn=univention,$(ldap_base)' can be deleted.
Check Well-known SID
Be sure, that all well-known SID are named with their english names. In a classic samba4 update there could be problems with non english groupnames of well-known SID. For all well-known SID see : Well-known security identifiers article.
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.
Version of Microsoft Windows older than Windows 2000 and Windows Server 2000 are not capable of joining into an Active Directory domain and should be replaced. We recommend migrating required services to UCS services or at least updating to a recent patchlevel of Windows 7 or Windows Server 2008 R2.
CPU and Memory
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 UCS domain controller Master and at least one UCS 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.
Also review the used software. This is true for both your UCS and your Microsoft Windows systems. Especially software distributed over multiple systems or software using UCS domain services for their authentication have to be considered.
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 branch offices should be connected to bigger ones and share their domain controller. The latest UCS 3 version 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
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 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 necessary 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.
Post Update Tasks
Once the update is completed you have to (re)start all your Microsoft Windows systems to allow them to reconfigure themselves to operation in an AD-domain. While this will happen for all clients once the work day starts, you might have to schedule it for the servers.