Context

This homelab had no internal name resolution for a long time — every machine's name-to-address mapping lived in a manually edited local file, copied by hand to every machine that needed it. That doesn't scale, and it doesn't let you practice anything resembling real identity management. So I deployed FreeIPA: the open-source upstream project behind Red Hat's enterprise identity management product, the kind of identity system common in the regulated environments I work in.

Why this one, specifically

FreeIPA bundles several things that are usually separate: a DNS server, a Kerberos authentication service (tickets instead of passwords crossing the network), a directory of users and groups, and an internal certificate authority. That combination — plus host-based access control, the ability to say precisely which accounts may log into which machines — is the kind of identity management shape you'd find in the regulated environments I work in. Reproducing it at home, with entirely local, invented accounts, is a low-stakes way to actually get hands-on with mechanics I'd otherwise only read about.

What building it taught me

• A DNS server that only forwards for itself is a very tidy way to create an impossible boot order. An early attempt to make the identity server responsible for resolving its own name created a loop — the server needed itself, resolvable, to resolve itself. Simple to fix, but a good concrete illustration of why a DNS design should never let something depend on resolving itself with nothing else to fall back on.
• Authentication succeeding doesn't mean a session is usable. A test login authenticated correctly — the identity and ticket-issuing side worked exactly as designed — and then failed anyway, because a completely separate piece of the login chain (the part responsible for creating a user's home directory on first login) wasn't enabled. It's a genuinely useful distinction: proving who someone is and giving them a working environment afterward are two different jobs, handled by two different pieces of the system, and either can fail independently of the other.
• Older platforms fight back on tooling, not just on the standard itself. Enrolling a deliberately old, still-supported Linux release surfaced a real version conflict between the identity client software and the automation tooling used to configure it — solved with an isolated, purpose-built automation environment just for that one older platform, rather than downgrading tooling everywhere and risking everything else.
• A DNS discrepancy is worth investigating properly, not assumed away. A stale, manually-entered name-to-address mapping disagreed with what the new identity system's DNS said — and the safe move was to trace the disagreement to its actual source (the service that really routes the traffic) rather than guess, twice, in the wrong direction first, before finding the real answer.

What I chose not to do

I deliberately did not extend this identity system's authority down to the physical machines that host the whole homelab — only to the services running on top of them. That's a conscious boundary, not a temporary one: the hosting layer stays independently manageable even if the identity system itself is ever unavailable.

The takeaway

None of this was about the destination — a working internal DNS and login system — so much as the practice of building one the way it's actually built professionally: staged, validated at every step, with real (if small) incidents along the way that mirror the kind of thing that shows up in a production identity rollout, just with far lower stakes.