Setting up Samba as an Active Directory domain controller is, however, straightforward because there is a provisioning tool that performs the setup tasks:
# samba-tool domain provision Realm [MYDOMAIN.CO.UK]: Domain [MYDOMAIN]: Server Role (dc, member, standalone) [dc]: DNS backend (SAMBA_INTERNAL, BIND9_ FLATFILE, BIND9_DLZ, NONE) [SAMBA_ INTERNAL]: DNS forwarder IP address (write 'none' to disable forwarding) [10.0.0.138]: Administrator password: Retype password:
Passwords need to be suitably complex: one upper-case letter, one digit and at least eight characters long. "Pa$w0rd" is a suitable example that we used for our tests, though is not very secure.
When the provisioning completes, it will explain that it has generated a Kerberos configuration suitable for Samba 4. You need to copy this file into place:
# cp /var/lib/samba/private/krb5.conf /etc
Next, the DNS resolver needs to be configured to point at Samba, because it is also the DNS for the new Windows domain. Do this either by editing /etc/resolv.conf or, if that is written by a service such as dhcpcd, adjusting the service's configuration. Either way, the /etc/resolv.conf should look like this:
domain mydomain.co.uk nameserver 127.0.0.1
Get daily insight, inspiration and deals in your inbox
Sign up for breaking news, reviews, opinion, top tech deals, and more.
Samba forwards requests that it cannot resolve itself to the DNS forwarding address that was specified during the provisioning step. It uses its own internal DNS server, but can be configured to use an external BIND DNS instead. However, because you get so much for free with the internal one, it probably isn't worth doing so unless you really need to.
With the configuration steps completed, we can start the domain controller and perform some tests. Active Directory mode uses a new samba binary instead of the usual smbd. Here, we start it in the foreground whilst testing:
# samba -i -M single mydomain Copyright Andrew Tridgell and the Samba Team 1992-2012 samba: using 'single' process model # host -t SRV _ldap._tcp.mydomain.co.uk _ldap._tcp.mydomain.co.uk has SRV record 0 100 389 myhost.mydomain.co.uk. # host -t SRV _kerberos._udp.mydomain.co.uk _kerberos._udp.mydomain.co.uk has SRV record 0 100 88 myhost.mydomain.co.uk. # host -t A myhost.mydomain.co.uk host -t A myhost.mydomain.co.uk
Next, test Kerberos (enter the administrator password when requested):
# kinit administrator@MYDOMAIN.CO.UK Password for administrator@MYDOMAIN. CO.UK: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administrator@MYDOMAIN.CO.UK Valid starting Expires Service principal 08/02/13 16:25:31 09/02/13 02:25:31 krbtgt/ MYDOMAIN.CO.UK@MYDOMAIN.CO.UK renew until 09/02/13 16:25:21
At this point, you should be able to see Samba shares and access them:
$ smbclient -L localhost -U% Domain=[MYDOMAIN] OS=[Unix] Server=[Samba 4.0.3] Sharename Type Comment --------- ---- ------- netlogon Disk sysvol Disk IPC$ IPC IPC Service (Samba 4.0.3) $ smbclient //localhost/netlogon -UAdministrator%'Pa$w0rd' -c 'ls' Domain=[MYDOMAIN] OS=[Unix] Server=[Samba 4.0.3] . D 0 Thu Feb 7 20:06:55 2013 .. D 0 Thu Feb 7 20:08:44 2013
Another service provided by an Active Directory Domain Controller is time synchronisation. Whilst optional, providing this service is highly recommended because Kerberos is highly sensitive to time variations between clients and the server. The so-called Windows Time Service that a domain controller provides is a Network Time Protocol (NTP) server with extensions for authentication.
Strange things can happen when clocks aren't synchronised
There are a number of NTP implementations on Linux, such as ntpd and open-ntpd, but only ntpd version 4.2.6 supports the necessary authentication extensions, and then only if that support has been compiled in (check your ntpd version with ntpd --version).
A suitably configured ntpd asks Samba to perform any necessary authentication. The ntpd configuration goes in /etc/ntpd.conf. Here is a suitable example:
The important lines, which may not be in an existing ntpd.conf, are the last two. The ntpsigndsocket entry defines the path to the directory where Samba places the socket file, through which it will receive authentication requests. The restrict entry tells ntpd that incoming requests need to be authenticated. The socket path is determined by Samba's configuration, and you can confirm the correct path with:
