One of the problems with trying to do things at low or no cost is that they don’t always work out as you want them to. This is especially true of IT. I have fallen victim to this once or twice in my working lifetime, especially of late. I’m a trustee and systems admin for a small charity and we, in common with other small charities, have a very limited budget, especially when it comes to IT. To save money on operating systems I opted to install a Linux box running Samba 4.5 to provide Active Directory services but, as always, requirements change. Having set up a Samba-based Active Directory service and successfully joined a set of Windows 10 Pro clients to it, there is now a requirement to interface the directory with Azure and Office 365, (as well as the GPO’s and login scripts not working). If this was a Windows based AD, there wouldn’t be a problem but, this is Samba and, so, to satisfy the requirements, a Windows 2012 or 2016 server has to be joined to the AD. Unfortunately, neither of these can join a Samba domain directly so this has to take place via a 2008 server. This isn’t as easy as it seems. It isn’t that hard but it is involved and can break the AD replication and make the directory unstable, if not unusable. So, this is how you do it…..
Please Note: Throughout this document, replace sambaDC, winDC, win_IP and domain.name with the names of your own Samba DC, Windows DC, Windows server IP address and domain name.
The Server & Active Directory
First off, due to the way Windows 2012 server interfaces with the domain (using MSRPC), it isn’t possible to join the Win2012 server directly. Samba AD operates at the 2008R2 domain level so anything lower than this will not work either so, we have to first add a Win2008R2 server, integrate the DNS and transfer the FSMO roles from the Samba server and then demote the Samba server.
Note: In a Windows only environment we would normally only be concerned with the standard five FSMO roles: Schema, RID, PDC Emulator, Infrastructure & Domain Naming. With Samba, there are two further roles that have to be transferred: DomainDnsZone and ForestDnsZone.
The following are basic steps that all Systems Administrators should be familiar with. If you’ve installed Windows server before then you’ll know what to do and can skip to the section “The Replication Tango”.
Provisioning The Server:
All that is required to start is a standard Windows 2008 R2 server installation. This can be on bare metal hardware or a virtual machine running on a hypervisor (I’m doing this on a Linux box with Xen Hypervisor 4.9).
Once the server has been installed, the first thing to do is add a static IP address, gateway, subnet mask and point the primary DNS entry to the Samba server and the secondary to the server itself. For example, I have a server with a static IP of 192.168.1.7 and the Samba server is 192.168.1.2, as shown here:
Next, the Active Directory Role binaries need to be installed. This is handled by the Add Roles wizard. In the Initial Tasks list, click on Add Roles. Once the Add Roles wizard starts, click Next to go past the “Before You Begin” screen and ensure that the “Active Directory Domain Services” check box is ticked and click Next. Click Add Required Features to allow .NET to be installed and then click Install to begin installing the binaries. Once this is complete, we can then join the server to the domain.
Joining The Domain:
The next step is to join the domain. To do this, we need to use a command line application called “dcpromo.exe“. This provides an interface to set up the server and join it to the domain.
- Press WinKey+R to open the Run dialog box, type in “cmd” and press enter. This should open a command prompt with admin rights by default.
- Type “dcpromo” and press . The wizard should start. (Once each page is complete, then click Next).
- On the first page of the wizard, check the “Use Advanced Mode Installation” box and click Next and then Next again.
- As we are adding a DC to the domain, select “Existing Forest” and then “Add domain controller to an existing domain“.
- Enter the domain name then click “Set” to add an account in the target domain that has domain admin rights.
- Select the domain that you want to add the DC to.
- Select a site. In a small domain this will default to “Default-First-Site-Name“.
- Ensure that “DNS Server” and “Global Catalog” check boxes are ticked. If “RODC” is ticked, then untick it as we want this DC to be writeable.
- You will receive a warning that a delegation for this DNS server cannot be created. Click “Yes” to clear this warning. You can ignore it.
- Ensure that “Replicate data over the network” is selected.
- Select “Use this specific domain controller” and select the Samba server from the list.
- Leave the Database, Log and SYSVOL folders at their defaults.
- Enter a DSRM password of your choice.
- Check that the settings are correct. If you want, you can save these settings just in case the process fails and you want to follow them again.
- The Active Directory installation will now begin. Click “Finish” when it completes.
You will now need to restart the server to complete the installation of the Active Directory.
The Replication Tango
SYSVOL & NETLOGON Replication:
Once the server is a AD DC, replication needs to be added. Normally, with two or more Windows servers, this is automatic. Unfortunately, as mentioned previously, Samba cannot act as an MSRPC (Microsoft Remote Procedure Call) server so, consequently, no replication takes place other than the basic directory contents which are replicated during the boot process. This means that, when the Windows DC has finished booting, there are no Netlogon or SYSVOL shares so these have to be activated manually and replication also has to be handled manually. In this case, we shall use Robocopy from Microsoft to handle SYSVOL replication.
First we need to enable the SYSVOL share. To do this, open a run dialog and run Regedit. Navigate to:
Set Sysvolready to 0 and save. Reopen Sysvolready and set to 1 and save again. Open the Run dialog and enter \\winDC_IP and press enter. This will bring up the server shares. You should now see the “SYSVOL” share.
To enable SYSVOL and Netlogon replication we need to use a file copy application such as Robocopy. This can be performed once, or it can be scheduled by using the Windows Scheduler. For now, because we will be demoting the Samba server, we will only need to replicate once.
- Download the Windows 2003 Resource Kit Tools from Microsoft and install them on a workstation, not the server. Once installed, copy “C:\Program Files (x86)\Windows Resource Kits\Tools\Robocopy.exe” to a location on the server, eg the Documents directory.
- On the server, open an admin level command prompt and navigate to the location where you saved robocopy.exe.
- Enter the following command and press enter:
robocopy \\sambaDC\SYSVOL\domain.name\ C:\Windows\SYSVOL\domain\ /mir /sec
You should see a list of files and directories being copied followed by a summary of what was copied…
Go to Run and open \\winDC_IP again and check that Netlogon and SYSVOL are there. If Netlogon is missing then reopen Regedit and set Sysvolready to 0 and save. Reopen Sysvolready and set to 1 and save again. Reopen \\winDC_IP and Netlogon should be visible. SYSVOL & Netlogon replication is now complete.
DNS & Zone Transfers:
Normally, DNS zone transfers are part of the replication process between Windows servers. Again, because Samba cannot act as an RPC server, DNS replication cannot take place in the normal way. Neither can the Windows server add itself to the Samba DNS server. This, too, has to be done manually.
To add the DC’s A Record:
To add the A record you will need to be logged into the Samba server and have a CLI open.
Check whether or not the A record exists by running the following command:
host -t A winDC.domain.name
If the A record doesn’t exist then you will see the following error:
host winDC.domain.name not found: 3(NXDOMAIN)
To add the record, execute the following:
sudo samba-tool dns add sambaDC domain.name winDC A winDC_ip -Uadministrator
Next, we need to add the objectGUID CNAME record. (This allows a client to locate any domain controller in the forest by looking up an A record). First of all, we need to find the objectGUID of the server. We can do this by running the following:
sudo ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid
This should produce a result similar to this:
record 1 dn: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name objectGUID: df4bdd8c-abc7-4779-b01e-4dd4553ca3e9 record 2 dn: CN=NTDS Settings,CN=sambaDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name objectGUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f returned 2 records 2 entries 0 referrals
So, we now know that df4bdd8c-abc7-4779-b01e-4dd4553ca3e9 is the GUID of the Windows domain controller, winDC. Now we can check to see if the CNAME record exists in the _msdcs.domain.name DNS zone by executing the command:
host -t CNAME df4bdd8c-abc7-4779-b01e-4dd4553ca3e9._msdcs.domain.name.
If the CNAME record does not exist then an error will be returned:
Host df4bdd8c-abc7-4779-b01e-4dd4553ca3e9._msdcs.domain.name. not found: 3(NXDOMAIN)
The record then needs to be created. The following command will create the record:
sudo samba-tool dns add sambaDC _msdcs.domain.name df4bdd8c-abc7-4779-b01e-4dd4553ca3e9 CNAME winDC.domain.name -Uadministrator Password for [DOMAIN\administrator]: Record added successfully
Once the DNS is confirmed and set up, we can then transfer the FSMO roles over to the Windows DC.
The Seven FSMO Roles:
In an Active Directory domain, there are five standard FSMO (Flexible Single Master Operation) roles. These roles are:
- Schema Master
- Domain Name Master
- RID Master
- PDC Emulator Master
- Infrastructure Master
There are two further roles that need to be transferred from the Samba server. These are:
Transferring the standard five roles is well documented and is no different in our scenario so, rather than repeat it all here, the relevant method can be found here.
The DomainDnsZone and ForestDnsZone roles require a slightly different transfer method. The normal way would be to use ADSIEdit on the Windows server but, because of the lack of replication, this won’t remove the roles from the Samba server and will cause the directory to become unstable.
To remove the last two roles you need to have a domain-joined Windows client with RSAT (Remote Server Administration Tools) installed. This machine needs to be connected to the Samba server, not the Windows server. In the RSAT tools, select ADSIEdit.
Right-Click on ADSI Edit in the top of the left-most pane and click Connect in the context menu. In the “Computer” section of the dialog box enter the FQDN of the Samba server into the drop-down box. Then in the “Connection Point” section, type the following:
and then click OK. In the leftmost pane you will see
Click on DC=ForestDnsZones and then, in the centre pane, double-click the entry “CN=Infrastructure”. Another dialog box will appear. Towards the bottom you should see an entry “fSMORoleOwner”. Double-click this and then edit “CN=sambaDC” and change the server name to that of the winDC. Click OK and then Apply and OK.
Follow the same procedure but change the connection point to:
Once completed, go to the Samba server’s CLI and type
sudo samba-tool fsmo show
You should now see all seven roles displayed with CN=winDC
SchemaMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name InfrastructureMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name RidAllocationMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name PdcEmulationMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name DomainNamingMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=winDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=name
Now that the FSMO roles are all transferred over, the Samba server can be demoted. To do this, run the following command:
samba-tool domain demote --server=winDC -Uadministrator Using winDC as partner server for the demotion Password for [DOMAIN\administrator]: Deactivating inbound replication Asking partner server winDC to synchronize from us Changing userControl and container Demote successful
The Samba server should now be demoted to a member server and can be rebooted. Once the server is back up, edit the dhcpd.conf file (if the Samba server is your DHCP server) so that the dns-nameserver option points to the IP address of the winDC. If you’re using a different DHCP server, ensure that it serves the clients with the DNS IP address of the winDC.
On the Windows DC, change the DNS options in the IPv4 settings to point to the server itself and it’s loopback (127.0.0.1). You can then manually remove the objectGUID CNAME record of the Samba server from the _msdcs.domain.name DNS zone. This will stop any attempt by further added servers from contacting the Samba server as a DC.
The final step is to run”dcdiag.exe” in an elevated command prompt. This will highlight any errors in the active directory which can then be attended to.
If all has been successful, then Windows clients can be rebooted and should log into the Windows 2008 Server. You can check this by logging onto a client and opening a command shell and typing the following command:
c:\> echo %LOGONSERVER% \\winDC
If the result is the Samba server then check the DNS settings of the DHCP server. It may still be pointing to the Samba server.
Now for the next step….
Coming up: Windows 2012: The Joining
The following sources were all used to perform the domain transfer. Some were direct instructions and some (such as the bugzilla’s) were used to determine workarounds for particular problems (of which there have been many).