Create a samba lab-domain: Difference between revisions

From SambaWiki
No edit summary
Line 24: Line 24:
The rename command takes the format:
The rename command takes the format:


<pre>samba-tool domain backup rename <new-domain-netbios> <newdomain-dns-realm> --server=<dc-to-backup> --targetdir=<output-dir> --no-secrets [creds]</pre>
<pre>samba-tool domain backup rename <new-domain-netbios> <newdomain-dns-realm> --server=<dc-to-backup> --targetdir=<output-dir> --no-secrets -UAdministrator</pre>


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:
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:
Line 30: Line 30:
<pre>sudo samba-tool domain backup rename LABDOMAIN lab.example.com --server=PROD-DC --targetdir=/root/samba-backups/ --no-secrets -UAdministrator</pre>
<pre>sudo samba-tool domain backup rename LABDOMAIN lab.example.com --server=PROD-DC --targetdir=/root/samba-backups/ --no-secrets -UAdministrator</pre>


Note that the <tt>--no-secrets</tt> 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.
Note that the <code>--no-secrets</code> 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 <tt>--configfile=smb.conf</tt> option). This ensures the backup will contain an smb.conf that closely matches your domain.
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 <code>--configfile=smb.conf</code> 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.
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.

Revision as of 04:07, 10 August 2018

Overview

Having a lab domain gives you a realistic environment for pre-production testing, without impacting your live network. It allows you to test new Samba releases prior to deploying the upgrade, and provides a sandbox for running tools like traffic replay.

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.

Steps Involved

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 database, renaming all the objects in the database as it goes. The resulting database files are then written to a .tar.bz2 backup-file. Note that the backup command does not have any side-effects on the production DC, apart from the extra overhead on the server (which is similar load to joining a new DC).

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

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 database files to reside. Note that you can't use default installation location (e.g. /usr/local/samba/) because the directory has to be empty (or not exist yet). However, you can specify a sub-directory underneath (e.g. /usr/local/samba/labdom), 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.

export RESTORE_DIR=/usr/local/samba/labdom

Now extract the Samba database files 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 database files on disk for a new lab domain. All the production user and machine accounts exist, but the lab database contains none of the passwords. The DN of every object in the database has been renamed, to reflect the change in domain name. Any traces of the production DCs have been removed from the lab database, and the lab domain now only contains the one DC you ran this command on.

Reset passwords

During the backup/restore, the password for the Administrator's user account is 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 database 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.

Starting up Samba

Before you start samba, double-check that the settings in the smb.conf look correct. e.g.

cat $RESTORE_DIR/etc/smb.conf

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