A guide on how to run a tightly secured Samba 4 based Active Directory Domain Controller to serve Windows 2000+ clients. This setup has the following advantages:
Static RPC ports, so you can have a firewall your clients and Domain Controller
Bind DLZ zones (dynamic LDAP zones), that can be managed through standard Windows Remote Services Administration Tools
Dynamic DNS updates (clients register themselves in DNS)
No insecure LANMAN, NetBIOS, SMB1 enabled. Security is higher, performance is much better!
This makes the installation much hardened and secure than the default Microsoft setup.
This is an update to my old post for the new stuff that has changed during the past year and the introduction of CentOS/RHEL 7.
System enablement
This guide is written against Samba 4.x for Fedora and CentOS/RHEL 7 and a minimum Samba version of 4.1.6, as it’s the first Samba release that includes systemd support. You can grab the latest Samba source packages from Koji.
Both require a patched Samba package to enable the missing Domain Controller functionality. Hopefully this change will make it into official packages when Samba will be built with the system’s MIT Kerberos implementation.
The first patch is for disabling MIT Kerberos integration and enabling optional Heimdal Kerberos with Domain Controller functionality in the Redhat/Fedora package. This has also been reported upstream:
Version change
Do not forget to bump the Epoch in the RPM spec file so packages do not conflict and are not overwritten by official packages with a lower epoch.
After patching, rebuild the packages with your favorite tools, rpmbuild, mock or koji, whatever your preference is.
Software installation
Install BIND server (required also for other optional domains), the NTP server, the Samba suite (the rpms you just rebuilt) and some additional tools used by our environment on the selected server. For servers; replace also firewalld with the base iptables service:
Networking
Disable IPv6
I had to disable IPv6 for my internal network, you might need to have it enabled. Do the following to permanently disable IPv6:
Firewall configuration
The following ports need to be opened on the server firewall:
TCP: 53, 88, 135, 445, 464, 1024-5000, 3268
UDP: 53, 88, 123, 389, 464
Ports 1024-5000 are for the RPC services used by Samba, and can be further reduced in case you don’t have many clients. Port tcp/53 is used by Bind to receive DNS GSS record updates (they use TCP, not UDP). It is also used for large zone transfers, but this is not our case.
Create the file /etc/sysconfig/iptables and insert the following contents (we are assuming the server has an IP address of 192.168.0.17):
Then start the firewall:
Provisioning the domain
First setup and provisioning can be executed with SELinux disabled to be later re-enabled. This helps debugging issues that are not otherwise present with DAC permissions. Execute the following commands as root to start the provisioning:
Alternatively it can be run without parameters and the installation will be interactive. An output like the following will be returned:
Disable NetBIOS
Edit the file /etc/samba/smb.conf and make sure that the [global] section contains the following lines (in addition to the others) to disable NetBIOS support:
Windows 2000 and later systems setup two connections simultaniously to a server one on port 445 and one on port 139. If it gets a response from port 445 it will reset (RST) the port 139 connection. If it only gets a response from port 139, that one is used. If you disable NBT (NetBIOS over TCP/IP) on your client only port 445 is being tried. Pre-Windows 2000 clients only use port 139.
Configure Kerberos
Copy the provision generated Kerberos file to the default system location:
Make sure the Kerberos configuration file contains the check-ticket-addresses directive; as it is required for clients connecting through a NAT; which is the case for our remote PCs.
Configure NTP server
Change the NTP configuration file to enable Microsoft signed time queries:
Change permissions of the NTP folders which should be accessible by the NTP daemon:
Configure DNS server
Look at the hints in the previous output regarding Bind and modify the file /etc/named.conf and remember to fill appropriately the zone files with the correct records. Replace my addresses with yours, of course.
The DNS server can also to be authoritative for additional stub zones hosted in the same BIND instance, as an example:
Change permissions to reach the folders containing the dynamic zones which should be accessible by Bind:
Disable IPv6 also on Bind, to avoid flooding the logs with unwanted messages. Add the following line to /etc/sysconfig/named:
Starting services
Make the Samba system use its Bind recursive DNS server as primary DNS. This is required for proper Samba 4 operation of the Domain Controller. Any external request made by the server will be forwarded through the POP DNS servers.
Edit /etc/sysconfig/network-scripts/ifcfg- and change the DNS1 line to read as follows:
DNS1=192.168.0.17
Then delete all other DNS* lines from the file. Afterwards restart the network:
Finally start Bind, NTP server and Samba:
Troubleshooting
For debugging, launch Bind, the NTP server and Samba with the following options to start them in the foreground:
MS-SNTP troubleshooting
To troubleshoot NTP settings, perform the following command on the Windows clients to check the Windows Time Service settings and status:
You should obtain an output like the following:
It identifies the last succesful sync time; the fact that the client / server communication is using MS-SNTP to communicate (Time Source Flags: 2 (Authenticated )) and that the last command was executed successfully.
In case it doesn’t work; to manually set Windows Time Service configuration to read NTP settings from the domain perform the following commands to reset the configuration and to sync again the client to the server:
Then check again the status with the previous command.
If the time server specified in the Windows client is a normal NTP server, then the Windows client will not ask for MS-SNTP signed responses. The command to synchronize the clock is as follows:
This is the output of the query:
Please note that the Time Source Flags do not list the sync as Authenticated.
Kerberos authentication
Test the Active Directory Administrator password and check that the Kerberos ticket and password policies are valid:
SMB/CIFS file sharing
You should now see all your local default shares by browsing:
To test that authentication is working, you should try to connect to the netlogon share using the Administrator password you set earlier:
To see that all the required DNS records are exposed in the DNS, launch the following commands:
DNS and GSSEC records insertion/deletion
To test DNS dynamic updates perform the following command on the Windows client:
This will create a DNS record for the system in the Active Directory DNS zone using a secure Kerberos authenticated update.
If the record does not appear start debugging on the server for DNS records availability and proper functioning of the DLZ zone. To proceed launch the following command with both Samba and Bind running:
This will fetch all the minimum required DNS records for Active Directory from the Samba database and try to re-insert them into the zone using a kerberized (GSSEC) DNS update to the Bind server.
In case you obtain the following message while trying to run the above command:
This means you have some problems with your current Bind Kerberos keytab file. Perform the following command to check that the service principals are contained in the file:
If you obtain an empty list like the one above, extra the DNS service principal with the following command.
After generation, make sure to check again its contents. If the file is totally corrupt, regenerate it and apply permissions again. You should have some contents like the following:
In case you’re guessing what are those weird record types (like RT) you see queried in Samba’s DNS by Windows Clients, please look at the following links:
http://www.iana.org/assignments/dns-parameters/dns-parameters.xml
http://technet.microsoft.com/en-us/library/cc758321%28v=ws.10%29.aspx
Windows client networking adjustments
Disable NetBios over TCP/IP
To make the necessary tests; make sure that the Windows system has NetBIOS over TCP/IP disabled in the Advanced TCP/IP settings configuration pane.
Windows 2000 and later systems setup two connections simultaniously to a server one on port 445 and one on port 139. If it gets a response from port 445 it will reset (RST) the port 139 connection. If it only gets a response from port 139, that one is used. If you disable NBT (NetBIOS over TCP/IP) on your client only port 445 is being tried. Pre-Windows 2000 clients only use port 139.
Disable Teredo IPv6 Tunneling
To disable IPv6 and Teredo IPv6 Tunnelling execute the following command as an Administrator in the Windows command prompt:
Disable NCSI testing
To disable Network Connectivity Status Indicator checking on Microsoft servers for internet connectivity, start the Group Policy Editor (gpedit.msc); navigate to the correct tree and set “Turn off Windows Network Connectivity Status Indicator active tests” to Enable.
Windows firewall integration
For Windows 7, the following ports need to be enabled in the firewall; all the other rules should be disabled. This is a subset of the ones listed in Microsoft’s Active Directory required ports:
Communications from the Windows client towards the domain controller:
TCP: 135, 445, 3268, 1024-5000
TCP/UDP: 53, 123, 88, 389, 464
Communications from the domain controller towards the Windows clients:
TCP: 135, 445, 1024-1048
TLS support for LDAP (local domain on 389 and Global Catalogue on 3268) is disabled because connections are made with SASL, using GSS-API and thus employing Kerberos and session-level encryption. For details on message integrity (signing) and message confidentiality (sealing) please see this nice article from the University of Washington that explains authentication in a simple way.
RPC ports can be as low as one, but in this case you lose a lot of the functionality. For example, running a scheduled task on Windows will open an additional RPC port (yes, that’s true), and if the system does not have any one that can be used, the process fails miserably. From my test in our office, 24 ports should be enough for domain management plus normal day to day desktop use.
To make the RPC server listen on port range 1024-1048; the following registry file needs to be applied and the system rebooted:
Please note, the following Windows commands will still return the full list of RPC ports for Windows services:
These are the commands required to add the Windows Firewall rules from the command line; they assume you want to enable the full 192.168.0.0/24 network where the Domain Controller will reside:
To debug connections, use the PortQueryUI command that you can download from the Microsoft website:
http://www.microsoft.com/en-us/download/details.aspx?id=24009