Providing Directory services to your family without losing your roots.

The computer proliferation problem

This post describes my experience and some choices that I made. It is a personal choice and I'm not saying that this the 'best way' (tm) to solve this problem, just that it is one of the possibilities.

I'm sure a lot of parents can relate to this.

Back then, life was simple: my kids would use the media library, surf the InterNet from the PC in the living room and type their documents on that box. The documents would be saved in a shared folder on the home RHEL Cluster and backups would hum at night.

Then, little by little things became more complex. The teenagers got their first laptops and life was good.. for a short while. I had agreed to keep the laptops under Windows (10). This made -my- life simple since patching firmwares/BIOS on Lenovo laptops is very Windows-friendly.

Since they had to use Microsoft Office for school, having that suite on their personal computers allowed them to work efficiently and occasionally play some games.

It appeared quite quickly that this didn't scale too well:

What if Teen #2 deleted the shared documents folder from her PC. Teen #1 and parents' documents would be gone too. This wasn't too resilient.
Since they all used local accounts (Wifey + two teenagers), this provided absolutely no security when the road warriors would go to school.
I wasn't teaching them well enough the importance of privacy and security by ignoring the problem.
I was going crazy going from PC to PC to help them with Windows settings.

The search for a directory solution

The solution was simple : We just needed separate user accounts and use directory services.

In addition to that, it needed to:

Play nice with the RHEL infrastructure which provided core services in the house (proxy, DNS, file sharing, firewalls, etc..)
Be redundant and resilient. And also not drive me crazy (I know -some- Windows things, just not Windows Server things).
Had to be low maintenance.
Play nice with the Windows 10 endpoints systems.
Allow Domain GPO's to manage the settings on the endpoints so I didn't have to log onto every account of every single laptop in the house to change a simple setting.

A list of solutions which were considered

Here's what I had short-listed after a few months of slow procrastination:

Stay on an NT4-style Domain and use that with RHEL's samba. Rejected : Microsoft and the rest of the world are busy getting rid of NT4 domains and SMB1. This isn't future-proof.
Use FreeIPA and pGina on W10. - Rejected: pGina would be a maintenance nightmare with W10 updates that tend to break stuff. This would play nice with RHEL systems and VMs but not with the W10 endpoints.
Run an AD infrastructure and use Centrify on RHEL/Linux hosts. - Rejected : I don't know enough to manage Windows Server Systems and Centrify. Plus, only the paying version of Centrify offered unified UIDs. Consistent UIDs weren't available in the 'free' version.
Use Windows Server 2012/2016 and create an AD domain. - Rejected : I had no experience managing Windows Server and since it is far from 'free', I couldn't consider running pirated software for the core of m authentication services.
Run a Samba 4 AD Infrastructure. - Almost Rejected : There were no AD-capable builds of Samba for RHEL due to kerberos compatibility issues.

Defining an implementation strategy

Once it appeared that a Samba 4 AD Infrastructure had the best chance of winning the deal, a plan was laid out:

Since Samba AD containers didn't seem to be too successful, rebuild rpms to enable AD in samba
If successful, create two dedicated RHEL VMs to become Samba AD DCs for the future AD Forest.
Join the W10 hosts to the Domain
Join the RHEL servers to the Domain so they could serve files and provide login servers through AD.

Big caveat : Obtaining RHEL rpms of Samba AD/DC.

After several attempts, it appeared that there wasn't a single reliable source of Samba AD rpms for RHEL. There were:

Centos rpms (these followed the RHEL rpms and had the AD part disabled).
EzPlanet rpms (in 2018, these provided a good starting point stopped receiving updates)
TranquilIT rpms (these didn't have source rpms available and often lagged behind current. Situation is much better in 2020, Thanks Denis!)
Fedora rpms (these had better SPEC files but often failed to rebuild on RHEL7).

Rolling my own Samba AD/DC rpms for RHEL

At the end of the initial investigation, I decided to roll my own rpms based on what I had gleaned and make them available on my site: https://nova.polymtl.ca/~coyote/dist/samba/

This allowed me to work in a semi-autonomous way where the sole external dependency of the directory services my family depended on would be the Samba source. Starting in April 2019, I did build some rpm sets of Samba AD/DC 4.x for RHEL7.

Setting up a lightweight Directory Services Infrastructure

After I was happy with the rpms, I simply followed the excellent Samba Wiki ([1]) and deployed two simple RHEL7 VMs (2gb RAM, 2 vcpus) on my hypervisors:

On each of those VMs, the are samba rpms are installed:

The AD DNS domain is a sub-domain of my main DNS domain (served by ISC Bind) and querying the list of users gives away the names of the entire family.

Looking at a specific user, we see that it is a member of our forest:

The Windows Endpoints

Most of the Family endpoints run Windows 10 and are joined to the Samba AD/DC Domain:

Thanks to RSAT and domain GPOs, I can now push settings to the endpoints without having to wait for a maintenance window (Think: 1am to 6am for a regular College Student):