Video summary
Can FreeIPA compete with Microsoft Active Directory?
Main summary
Key takeaways
Video Overview
The video discusses whether FreeIPA can replace Microsoft Active Directory (AD) for identity and policy management, then demonstrates FreeIPA’s centralized authentication/authorization capabilities and deployment guidance.
Why Identity Management Matters
As a business grows beyond a few employees/computers, you need centralized control over:
- user accounts and passwords
- who can access which systems
- consistent “cohesive management” of identities
Microsoft AD (and cloud variants like Entra/Azure AD) is described as the long-standing industry standard for ~20 years, but the speaker raises concerns about long-term reliability and support.
Critique of Relying on Microsoft Support/Product Changes
The speaker highlights risks when your identity platform depends on a vendor’s ongoing product/support decisions, including scenarios like:
- If a Microsoft Entra tenant is deleted, the business could be effectively locked out.
- Microsoft support can be difficult to reach (and may be filtered/handled via AI), which increases perceived dependency risk.
Conclusion: Active Directory is powerful, but the speaker argues you shouldn’t assume Microsoft will maintain or support specific capabilities “forever,” especially given changing products and support models.
What FreeIPA Is (Positioning vs AD)
FreeIPA is presented as an identity and policy management solution for:
- account/credential management
- authentication across a network
- centralized policy and audit-related management
It’s not just an AD clone:
- It’s an independent open source project developed by Red Hat
- Enterprise support is available via Red Hat, while the system can still be run using its open source form
Goal: a “thorough organizational identity, policy, and audit management” setup.
Email Aside (Sponsor Integration)
Before continuing the main technical topic, the sponsor mentions Proton Unlimited for privacy-focused email hosting.
- Access via Proton app/web
- Bridges for IMAP/POP3/SMTP clients (encryption is handled by Proton)
Practical FreeIPA Demo: Onboarding and Access Control
User and Group Management
The speaker:
- creates a new user (example: Flax) in FreeIPA
- adds the user to a group (example: sales)
This group membership is then reflected on systems using Linux-style UID/GID permissions.
Domain-Joined Workstation Behavior (Fedora Example)
A Fedora machine is “domain joined” via FreeIPA. The workstation can authenticate users against FreeIPA.
When the user logs in:
- they are forced to change password
- they receive access to resources based on group permissions
File Access via Groups and NFS + Kerberos
The speaker shows access to a corporate share (example path under a domain folder like /corp), claiming:
- no manual mount configuration was needed on the host
- FreeIPA manages NFS shares and auto-mounts them
- NFS access uses Kerberos credentials
- access is granted through Linux group ID (GID) mappings propagated from FreeIPA groups
“Single Sign-On” Behavior Using Kerberos Tickets
The video argues Kerberos-based SSO differs from “shared password across apps.”
The described model:
- Logging into a workstation generates Kerberos tickets
- Accessing a domain web resource lets the server validate the ticket and determine group membership
- Example: checking whether a user belongs to a group like sysadmin
Result: users can access resources without logging in via a web page, assuming Kerberos integration is correctly configured.
SSH and Sudo Controls
The speaker demonstrates:
- SSH access restrictions based on FreeIPA policies
- sudo permissions centrally governed
Policy areas mentioned include:
- host-based access control (who can SSH where, etc.)
- sudo policy (what elevated actions users can perform)
How Access Rules Are Structured
The video presents an example policy pattern:
- a group like “people” inherits from real user groups (engineering/finance/sales/sysadmin)
- it determines access to workstations
Workstations/servers are managed via host groups, and policies reference those host groups.
Under-the-Hood Architecture (Why It Works)
FreeIPA integration is described as “multiple protocols wrapped together,” with a web UI—similar in spirit to AD.
Key components:
- Directory service: LDAP
- references 389 Directory Server as the open source implementation
- Authentication: Kerberos
- Ticket Granting Server model
- tickets last for resource access durations (not every request re-contacting the TGS)
- encryption described as AES-based (the speaker claims this is “quantum safe”)
- Kerberos + LDAP + DNS integration enables domain join setup to work smoothly for services like NFS and web authentication
Deployment Guide: Key Requirements and “Tips & Tricks”
Official Support / OS Requirements
- FreeIPA server support: Red Hat Enterprise Linux and Fedora
- the speaker notes Rocky may work, but isn’t officially supported beyond RHEL/Fedora
- FreeIPA client compatibility: wide Linux client support
- the speaker notes Debian/Ubuntu families work for clients
Kerberos and Time Synchronization (Critical)
- time must match between systems within a couple minutes
- installer/config scripts aim to set up chrony
- special note: in LXC containers on Proxmox, time sync may require disabling chrony because containers can’t modify the system clock
DNS and Naming Conventions (Critical; Hard to Change Later)
The speaker strongly recommends:
- decide DNS domain/realm naming early
- start with a test domain and rebuild once you’re confident
Kerberos + FreeIPA requires:
- forward and reverse DNS to work correctly
- hosts using fully qualified domain names (FQDNs) (e.g.,
host.domain.tld, not justhost)
Using FreeIPA for DNS Updates
FreeIPA can act as authoritative DNS for its zone and update:
- its own records
- client records on enrollment
The speaker recommends using a separate subdomain or different domain for the FreeIPA realm to avoid mixing internal Kerberos zones with production/public web zones.
Reverse DNS Pitfalls
Reverse DNS correctness is emphasized as required for Kerberos.
Workaround shared:
- use a local DNS resolver (example: Technitium) to override/handle reverse DNS for an IPv6 prefix
- forward reverse DNS zones to the FreeIPA server
Warning:
- NAT IPv4 / overlapping subnets can cause Kerberos problems because clients must reach correct reverse DNS.
Client Enrollment Tutorial (Proxmox VM + cloud-init)
The demo enrolls a new VM using Proxmox and cloud-init:
- starts from a Fedora template
- configures DNS/domain settings
- installs the FreeIPA client
- runs an enrollment command conceptually like:
ipa-client-install
The process includes:
- auto-discovery of the domain controller
- credentials from an IPA admin (or delegated enrollment user)
- enrolling machine certificates and Kerberos principals
- registering DNS automatically
- setting up items like SSH as part of enrollment
Post-enrollment Admin Step
Add the new host to the correct host group (e.g., servers/workstations) so policy rules apply.
Future Plans / Migration Strategy (Speaker’s Context)
The speaker plans to keep using FreeIPA, but rebuild domains after lessons learned:
- test domain (e.g.,
appleor.test) will be deleted - new FreeIPA domain planned under a real owned domain (example:
appleor.fee)
They also mention scaling FreeIPA to:
- CDN/network infrastructure
- certificate management
- FreeIPA provides a certificate authority and can automate cert issuance
- mutual TLS is referenced
DNS cutover plan:
- migrate DNS authority from a manual DNS tool (e.g., Technitium) to FreeIPA-managed DNS during cutover
Guides / Tutorials Explicitly Referenced
- FreeIPA official quick start guide: recommended to read first
- Speaker’s own referenced materials:
- a prior video about DHCP not being an inventory
- a prior video/script about Proxmox cloud-init templates
- note: IPA can help with DNS update integration if configured properly
Main Speakers / Sources
- Main speaker/source: the video author/host (“Apple R’s Adventures”)
- Referenced organizations/projects:
- Red Hat (FreeIPA development)
- FreeIPA project
- MIT (Kerberos origins)
- Microsoft (Active Directory/Entra)
- Proton (email sponsor)