Migrating to Samba

If you already have an Active Directory domain using Microsoft Windows servers and they manage your DNS, then the entire DNS issue can be side-stepped unless your intention is to migrate entirely to Samba. Alternatively, you can use BIND DLZ integration, which allows the Samba DC to maintain a DNS domain in BIND and gives the administrator the same ability to perform BIND-based update notification, zone transfer, and so on. The downside of BIND DLZ integration is that it adds another component to the stack, albeit one with which most administrators are very familiar.

When creating or migrating an existing NT4 domain to Samba, the built-in DNS server will be used by default. This simple DNS server is adequate for small sites, but it lacks much of the power and flexibility of BIND. To change the default back end to BIND when creating or migrating a domain, specify the --dns-backend=BIND9_DLZ option.

If a domain is initially provisioned with the internal DNS server, it subsequently can be migrated to BIND DLZ using the samba_upgradedns script; then, you just configure the BIND DLZ module.

With either DNS back end, the DNS domain of the Active Directory domain can be managed with the Windows domain management tools. In fact, this is the case with all of Samba's features: You can manage the Samba server in the same manner you would manage a Microsoft Windows server via the Microsoft Management Console (MMC). Administrators familiar with using MMC will be unaware that they are managing a non-Microsoft platform.

If you migrate or provision your domain initially using the built-in DNS server – which is the simplest route – and then decide you need the additional flexibility provided by BIND integration, you can migrate the domain's DNS using the provided samba_upgradedns script.

The major caveat of using BIND integration is that you need an up-to-date version of BIND. Although it is possible to get BIND 9.7.x to function, a version of 9.8.x or greater is strongly recommended. The function of secure updates and support for Kerberos have been evolving parts of BIND rapidly; being current can help you avoid headaches.

A recommended approach to DNS is to use a separate domain or sub-domain for the DNS zone of Active Directory. This eases migration when adding Active Directory to an existing network. If your current domain is example.com and your DNS servers resolve the names in that domain, you can create your new AD domain as ad.example.com . Next, you can configure your existing DNS servers to delegate resolution of that domain to your DC DNS servers.

On a Samba DC that is a DNS server, you can add the following:

[global]
    ...
    dns forwarder = 192.168.1.46

to the global section of the smb.conf file. If 192.168.1.46 is your existing DNS server, the DC will forward all requests for zones other than its own to your existing DNS server. With the delegation on your existing DNS and the forward in the AD DNS, you will be able to provide a seamless transition as you roll out AD. If you start with the Samba-provided internal DNS, once everything is working, you can then consider migrating to the BIND DLZ back-end DNS. It is much easier to isolate issues if you roll out the domain step by step.

The issue of sysvol replication is more tedious. In the sysvol replication are the files that represent the Group Policy objects of the domain, as well as any login scripts. This shared volume must be present on all the DCs accessible to clients.

When changes are made to login scripts or GPOs, these files must be pushed out from the origin DC to all other DCs. On a Samba DC, this replication must be performed using tools like rsync and csync. The Samba mail list archive has a script for this purpose [4]. The ACLs applied to the files on the sysvol volume are critical to the correct operation of clients. If manually, or by attempted replication, you end up with incorrect ACLs, samba-tool can be used to reset them to the expected values:

samba-tool ntacl sysvolreset

This command also should be performed when Samba is upgraded from one release to another. Fortunately, replication of the sysvol volume does not need to occur in real time. With tools such as rsync or csync, this process can be performed efficiently as a scheduled job.

Once the domain is provisioned and DNS and Kerberos have been tested, you can begin joining workstations to your domain. If you migrated to the Active Directory domain from a Samba NT domain, the workstations should retain their domain membership; they will switch to using Active Directory automatically.

Upgrading from NT4 to AD

Upgrading is almost as seamless as provisioning a new domain. The most important thing to know about an upgrade to Active Directory is that it is one-way. Once a workstation joined to an NT domain sees an AD domain with the same SID or NetBIOS name, it switches into Active Directory mode, and it will never go back to using the NT-mode DC.

Therefore, you should test the upgrade of your domain carefully, isolated from your production network, or you could end up committed to a test instance of your DC. Microsoft's Active-Directory-enabled clients naturally work this way and is not specific to using a Samba AD DC.

To perform the upgrade, you can use samba-tool domain upgrade support. The tool must have access to a copy of the smb.conf file used by one of your DCs, as well as copies of the TDB files. These files can be transferred to your testing server, for example, via rsync or scp. If your NT4 DC is using ldapsam, the testing host must also have access to the DSA as configured in the smb.conf file. The migration script only reads from the ldapsam, so nothing in the existing NT4 SAM will be modified:

samba-tool domain classicupgrade --dbdir=/tmp/x --use-xattrs=yes --realm=EXAMPLE /tmp/x/smb.conf

The dbdir option specifies the location of the NT4 domain controller's TDB files, and realm specifies the DNS zone for the new AD domain and the location of a copy of the NT4 DC's smb.conf file.

Provided your NT4 SAM is coherent, the migration script should migrate all your users, groups, and machine accounts. When migrating from an ldapsam, especially, you likely will run into some inconsistencies (e.g., duplicate usernames, SIDs, or missing groups) that will cause the migration to fail; fortunately, the error messages tend to be self-explanatory. If you are migrating from an ldapsam that has existed for a long time, it can become apparent why Samba needs to manage all services itself: The lazy NT4 DC will continue to operate in spite of numerous inconsistencies. Assume that any errors are legitimate problems with your NT4 SAM, address the issues there, and then re-attempt migration until it completes.

One real advantage Samba lends to sites still using NT4 domains is that it provides an upgrade path to Active Directory. All the migration tools I am aware of for migrating an NT4 domain to an Active Directory domain are no longer available for current Windows Server versions, Current Windows clients will not interoperate with an NT4-style domain without some registry hacking and, even then, not completely. Samba can at least provide a path for such sites to migrate to AD by adding Windows DCs and demoting the Samba DC, leaving an all-Windows AD domain, although one hopes the administrators of such sites will recognize the benefits and flexibility of the Samba DC and choose to keep it around.

Now that your Samba AD is up and running, you can fire up MMC on a Windows client and start managing your domain (Figure 2). Alternatively, many common operations, such as adding a user or DNS entries, can be accomplished with samba-tool (Listing 2).

samba-tool user add fbaggins
   --random-password --use-username-as-cn
   --surname="Baggins" --given-name="Frodo"
   --initials=S --mail-address=fbaggins@example.com
   --company="Hobbiton Inc." --script-path=shire.bat
   --profile-path=\\\\mydc.example.com\\profiles\\fbaggins
   --home-drive=F
   --home-directory=\\\\myfileserver.micore.us\\fbaggins
   --job-title="Goes there and back again"

Figure 2: Editing a DNS on a Samba DC via MMC.

Once up and running, Samba stores your domain information in a set of interlined LDB files. The database (SAM) content can be modified via samba-tool, via LDAP, or with Samba's ldbsearch, ldbmodify, ldbdel, and other corresponding commands. Once your domain is up, you might want to add additional information about users, such as phone numbers. You can generate LDIF files to import using LDAP or LDB tools or directly via LDAP using any Python bindings that support the Kerberos Generic Security Services API (GSSAPI).

Winbind and other services on Samba 3 or Samba 4 domain member servers (not DCs) work just as they did previously. Just remember to run smbd, nmbd, and windbind – on member servers, not the unified samba daemon.

Timekeeping

After you have domain workstations and servers joined to the domain, you will notice that clocks drift. Occasionally, you will lose access because of Kerberos's time sync requirements, so you must verify that Samba and NTP configurations correspond and that both have adequate access to the specified directory:

# Check the configuration of Samba
$ testparm --parameter-name="ntp signd socket directory"
/opt/s4/var/ntp
# Check configuration of NTP
$ cat /etc/ntp.conf
...
ntpsigndsocket /opt/s4/lib/ntp/
restrict default mssntp
# Change permissions of target folder
$ chown ntp /opt/s4/lib/ntp

Microsoft domain clients will not synchronize to your standard NTP time service because they require one that has been signed by a DC they trust; therefore, you must install a version of the NTP server on your DCs that supports packet signing (i.e., any version of ntpd after v4.2.6, provided it was built with the --enable-ntp-signd flag). The version of NTP that shipped with RHEL6/CentOS6 and Ubuntu 11.04 is too old and does not support signing.

Provided you have an adequate version of NTP installed, you now need to configure Samba and NTP to communicate with each other. This occurs via a filesystem socket. Samba will create a socket to which NTP can submit clock responses to be signed. NTP will then reply to the client with those signed responses.

The default location of the socket created by Samba is <prefix>/var/ntp/, where <prefix> is the installation prefix of your Samba build or package. Alternatively, you can specify the location using the ntp signd socket directory directive in the global section of the smb.conf file. In the ntp.conf file, ntpsigndsocket is used to indicate the same directory.

The very confusing aspect of this setup, in both Samba and NTP, is that these configuration directives do not indicate a file, they indicate a folder where a filesystem socket named socket is created and then expected to be found. When you restart samba, you should see a socket named socket in the directory you specified and Samba listening on that socket:

$ sudo ls -l /opt/s4/var/ntp/socket
srwxrwxrwx 1 root root 0 Feb 12 14:42 /opt/s4/var/ntp/socket
$ sudo fuser -u /opt/s4/var/ntp/socket
/opt/s4/var/ntp/socket: 1124(root)

The output from the fuser utility verifies that the automatically created socket is open by process 1124 (samba). On a Windows client, it is critical that the command

w32tm /resync /rediscover

completes successfully; you should see the message, The command completed successfully . If this command does not complete, time signing is not configured, and you are at risk of clock drift disabling parts of your domain.

With time synchronization, you now have a completely functional and stable Active Directory domain up and running – courtesy of GPL code.