Create a samba lab-domain
Having a lab domain gives you a realistic environment for pre-production testing, without impacting your live network.
In the past, setting up a samba lab domain has been difficult. The main problem is that running a second Samba domain with the same NETBIOS name and DNS realm will cause chaos on your production network if traffic from the two domains ever mixes. So you have to completely isolate all traffic from the lab domain from the rest of your network, which has proven very tricky to get right.
You can now avoid this headache by using the domain rename tool, which essentially creates a clone of your production domain with a different NETBIOS name and DNS realm.
The basic steps involved in creating a lab domain are:
- Generate a 'rename' backup of one of your production DCs.
- Restore the backup-file onto the lab DC.
- Reset any passwords needed for testing the lab domain.
- Start samba on the lab DC.
- Join subsequent DCs to the lab DC as needed, to scale the lab network.
The rest of this page walks through these steps in more detail.
Generate a renamed backup
The first step is to take a 'rename' backup of one of your production DCs. This clones the production DC's DB, renaming all the objects in the DB as it goes. The resulting DB files are then written to a .tar.bz2 backup-file.
The rename command takes the format:
samba-tool domain backup rename <new-domain-netbios> <newdomain-dns-realm> --server=<dc-to-backup> --targetdir=<output-dir> --no-secrets [creds]
You need to specify a new NETBIOS name and a new DNS realm for the lab domain. The targetdir is just the location where the generated backup-file will be written. For example, the actual command you run might look something like:
sudo samba-tool domain backup rename LABDOMAIN lab.example.com --server=PROD-DC --targetdir=/root/samba-backups/ --no-secrets -UAdministrator
Note that the --no-secrets option excludes the sensitive password information (i.e. attributes like unicodePwd, lmPwdHistory, etc) for all the users in the domain. However, the backup-file can still contain potentially sensitive information, such as all the user account-names in your network, or any confidential attributes you've added.
You should be able to run the backup command on the machine you'll use as your lab DC (providing it has connectivity with your production domain). In this case, it's a good idea to have an smb.conf file that closely matches your production DC and pass this to the backup command (i.e. using the --configfile=smb.conf option). This ensures the backup will contain an smb.conf that closely matches your domain.
Otherwise, if you ran the backup command on another machine (e.g. the production DC itself), then copy the generated backup-file onto your lab DC machine, ready for the next step.
Restore the backup-file onto the lab DC
Next, decide on a directory location on your lab DC where you want the samba DB files to reside. Note that you can't use /usr/local/samba/ because the directory has to be empty (or not exist yet). However, you can specify a sub-directory underneath /usr/local/samba, if you wanted to. We'll refer to this directory a lot in the next few commands, so let's set it as a bash variable.
Now extract the samba DB from the backup-file using the 'restore' command, which has the format:
samba-tool domain backup restore --targetdir=<output-dir> --newservername=<new-dc-name> --backup-file=<tar-file>
You pass it the backup-file generated in the previous step, along with the server-name the new lab DC will use. The actual command you run might look something like:
sudo samba-tool domain backup restore --targetdir=$RESTORE_DIR --newservername=LAB-DC1 --backup-file=/root/samba-backups/samba-backup-lab.example.com-2018-08-09T13-03-38.817855.tar.bz2
You now have the DB files on disk for a new lab domain. All the production user and machine accounts exist, but the lab DB contains none of the passwords. The DN of every object in the DB has been renamed, to reflect the change in domain name. Any traces of the production DCs have been removed from the lab DB, and the lab domain now only contains the one DC you ran this command on.
During the backup/restore, the password for the Administrator's user account got reset to a randomly-generated password. You probably want to change this to something easier to remember (but not the same as your production domain). You can just update the DB locally on disk, by running:
samba-tool user setpassword Administrator --newpassword=<password> -H $RESTORE_DIR/private/sam.ldb
For testing user authentication, etc, you may want to either add extra 'test' user/machine accounts or 'commandeer' some of the accounts copied from the production domain. The accounts copied from the production domain will not have passwords set, so you could reset passwords for selected accounts at this point too. Or you could do this later, once samba is actually running on the lab DC.
Before you start Samba, double-check that the settings in the smb.conf look correct. E.g.
Once you're happy, to start samba on the lab DC we need to specify the smb.conf we just restored. This will ensure samba loads the correct DB files for the lab domain. E.g.
sudo samba --configfile=$RESTORE_DIR/etc/smb.conf
Once samba has started up, you can perform some basic checks that your lab DC is operating correctly, e.g.
ldbsearch -H ldap://LAB-DC1 -UAdministrator
Join subsequent lab DCs
Once you're happy that your new lab DC is operating correctly, you can scale the size of your lab network by adding in more DCs. On the new DC machine, simply join it to the existing lab DC, e.g.
samba-tool domain join lab.example.com DC --server=LAB-DC1 -UAdministrator
See Joining a Samba DC to an Existing Active Directory for more details.