Best Practice Samba 4 Migration

From Univention Wiki

Jump to: navigation, search
Produktlogo UCS Version 3.0
Produktlogo UCS Version 3.2

This Best Practice Guide is trying to support you while migrating from 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.

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

Samba SIDs

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>'
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 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>'
Name sambaSID
Administrator 500
Guest 501

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.

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

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.

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 Microsoft 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

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.

Software Review

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.

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

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

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

Personal tools