Let's Build Active Directory With Samba
Let's provide Active Directory service on a
non-Microsoft operating system.
We will do this with the Samba system,
which includes an LDAP server and the
implementation of Kerberos 5.
Samba has provided SMB/CIFS based file and print service
for a long time.
Samba 4 added the ability to run a full
Active Directory service collection.
Here is the plan for this project: First, set up the needed DNS infrastructure on an existing BIND master (or primary) DNS server. This will include some peculiar looking SRV or Service records, plus the often overlooked PTR records for IPv4 and IPv6.
Second, install FreeBSD on a Raspberry Pi, reconfigure it for specific IPv4 and IPv6 networking, and add the needed packages. We're using free software on a free operating system, so let's also use very low-cost hardware. We will need to modify a file system to provide the required security features.
Third, make the new FreeBSD system into a slave (or secondary) DNS server.
Fourth, do the Samba-specific steps to make it an Active Directory server
Then we can deploy users and groups in the LDAP directory, and users and keys in the Kerberos database.
What is Active Directory?
To be honest, I really thought that Active Directory meant an enormously complicated collection of Microsoft-specific services, all of which communicate through arcane Microsoft-specific protocols, in order to accomplish some Microsoft-specific tasks.
Active Directory is simply Microsoft's bundle of DNS,
LDAP, and Kerberos.
Windows systems make some unusual DNS queries to discover
the Domain Controller, the Windows server
providing Active Directory service.
"Domain" is used in the Microsoft sense,
not as in DNS or Domain Name System,
although your Microsoft Domain name is probably related
to your DNS domain.
AD domains can be grouped into trees,
and multiple trees and domains into a forest.
The LDAP service provides
(among other things) the definitions of users and groups,
analogous to the
The Kerberos service enforces
analogous to the
or whatever you have specified via
Once that succeeds, Kerberos enforces authorization
and the use of cryptography.
With Kerberos you must first prove who you are
then the Kerberos server decides whether or not you're
allowed to use any specific service (authorization),
and if so, how to protect the communication (cryptography).
Or at least that's my take on Kerberos security. Ultimately, authorization is up to the Kerberized network server that is providing whatever service the user wants. I see it as being like going somewhere on an airliner. The airline could refuse to issue you a ticket. Or, they could issue you a ticket but then refuse to let you onto the plane. Either way, you can't go on the trip. You must both get a ticket and be allowed to use it.
Planning User and Group Administration
Microsoft's LDAP within Active Directory imposes some limitations, as it contradicts some details of the LDAP definition. For example, you cannot have user accounts with identical user names in separate OUs (or Organizational Units) within a domain. This imposes limitations in universities, public school systems, or other large organizations as they probably cannot use a scheme like "first initial, middle initial, family name" because there are too many people in different departments with the same initials and family name. Microsoft's design imposes this limit because it relies on the principles of NetBIOS and MS-DOS LAN Manager. LDAP goes back to 1971, four years before the founding of Microsoft, so NetBIOS and MS-DOS LAN Manager were bad decisions. Current specifications for LDAP are RFC 1823, RFC 2307, RFC 3062, and RFC 4533.
Linux and BSD systems are typically configured to create a private primary group for every user. A user will be the only member of a group by the same name, and as that user's primary group, newly created files will be affiliated with that group.
However, Windows' version of LDAP does not allow a user and
group with identical names.
I don't see this as a drawback, because a private primary
group seems to solve rather minor problems.
The main advantage is that turning on group permissions usually
has no effect.
To give others access you would have to either turn on
world permissions or use the
The risk of the first case should be obvious,
and the second requires knowing enough that the user
would probably be careful.
You can make the
adduser command assign a
generic user group instead of creating private primary groups.
On Linux, put
in the file
New users will have a primary GID of 100, typically
GROUP variable in the file
/etc/default/useradd to change the default
On OpenBSD, replace
in the file
On FreeBSD, run
when it asks you about the login group.
The result is stored in
Yes, you could edit that file directly, but it's safer
to answer the questions and let the command do it correctly.
Kerberos Security and Intercompatability
Microsoft's version of Kerberos bundled into Active Directory has had a bad reputation, but the criticism is outdated. Here's an explanation based on Chapter 5 of Windows Server 2003 Security Infrastructures.
Microsoft uses the PAC or Privilege Attribute Certificate in a non-standard way, and they took a lot of criticism after the release of Windows 2000. The complaints led them to eventually release their non-standard PAC specification, wrapped within dire warnings not to implement their version.
Most non-Microsoft Kerberos implementations simply ignore the PAC field. All the same, the non-standard PAC initially led to interoperability problems. If a user is in a large number of groups the PAC becomes too large to fit into one UDP packet. When that happens, a Windows KDC or Kerberos server asks the client to switch to TCP, but some early Kerberos implementations could not do this. However, TCP exchanges were standardized in August 2007 by RFC 5021. It would take a rather old implementation to not support TCP.
Kerberos 5 added Preauthentication. The very first packet, the request for the TGT (or Ticket-Granting Ticket), used to be the only thing in plaintext. The theory was that the TGT was encrypted with the user's symmetric key, derived from the password, and so it was safe to send an encrypted TGT to any requester. Preauthentication requires the initial TGT request to include the result of encrypting the current timestamp with the user's symmetric key. The KDC decrypts and verifies that the requester used the appropriate key before sending the encrypted TGT.
Without preauthentication, an attacker can request an encrypted TGT and then do an off-line password-cracking attack. The kerbcrack tool was designed for Kerberos password cracking. Try a large number of potential passwords, generate the corresponding keys, and see if the encrypted data decrypts to a valid TGT data structure.
With preauthentication, an attacker could capture a TGT request with preauthentication and, knowing that the hosts in the Kerberos realm must have synchronized clocks, do an off-line password-cracking attack. In this case, use kerbsniff to capture the TGT request packets, then use kerbcrack to search for a password-based key that decrypts the preauthentication field to a reasonably close timestamp.
Yes, both cases are partial known-plaintext attacks. But Kerberos uses AES-128 and AES-256, DES and RC4 are deprecated (see RFC 3962 and RFC 6649). The ciphers are quite strong. The weak link, by far, is the user-selected password.
In a hub-based Ethernet LAN, an attacker could passively listen for TGT requests with preauthentication. But on a switched LAN, an attacker would have to run a massive ARP spoofing attack in order to capture packets moving between a large number of client hosts and the KDC.
To place this in its historical context, Kerberos versions 1-3 were only used within the MIT campus. Kerberos 4 was published in the late 1980s and primarily targeted at MIT's Project Athena. Kerberos 5 was published in 1993, currently described by RFC 4120. So, kerbsniff and preauthentication capture would have been quite useful in the early years of Kerberos 5 when hubs were still used. But not in our current era of switched networks.
Security is limited by the fact that we human users aren't going to use pass phrases strong enough to prevent another human from finding them with the aid of a fast computer program.
Other Windows Server Tasks
There are some Windows-specific tasks that can take place within an Active Directory environment. For example, Active Directory Certificate Services, and Active Directory Rights Management Service. Add Windows Servers for those as needed, as Microsoft warns against doing anything else on an Active Directory Domain Controller.
The more I read this description of Active Directory, the more it looks to me as if AD is a scheme to sell Windows Server products. You need multiple AD servers, each on its own dedicated host [per Microsoft]. Other Microsoft products such as SQL Server and Exchange can interfere with the AD service operation [per TechRepublic, Microsoft Support, Microsoft TechNet, Microsoft Technet again, and again, and again]. File service and print service can also interfere with Active Directory service on the Domain Controller.
Let's start replacing the Microsoft Server platforms, starting with the Active Directory domain controller. Here we go with Samba...
The first step
The first step is to set up DNS records.