Raspberry Pi running Active Directory, using Samba on FreeBSD.

Active Directory with Samba and FreeBSD

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

Not really.

Active Directory is simply Microsoft's bundle of DNS, LDAP, and Kerberos network services, with back-end processes maintaining various databases. 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 /etc/passwd and /etc/group files. The Kerberos service enforces authentication, analogous to the /etc/shadow file or whatever you have specified via PAM. Once that succeeds, Kerberos enforces authorization and the use of cryptography. With Kerberos you must first prove who you are (authentication). Then the Kerberos server itself and the "Kerberized" (or Kerberos-aware) network server decide 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 included some 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 chgrp command. 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 USERGROUPS_ENAB=no in the file /etc/login.defs. New users will have a primary GID of 100, typically users. Set the GROUP variable in the file /etc/default/useradd to change the default user group.

On OpenBSD, replace group =uid with group users in the file /etc/usermgmt.conf.

On FreeBSD, run adduser -C and enter users when it asks you about the login group. The result is stored in /etc/adduser.conf. 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. 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 Kerberos over TCP.

Preauthentication

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 from which the key is derived.

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.