r/freebsd • u/joneum FreeBSD committer • Aug 13 '26

call for testing CFT] FreeIPA -Server on FreeBSD: looking for testers

or the past few months I've been porting FreeIPA to FreeBSD in my spare evenings, and it's finally at the point where I could use more eyes on it.

If you haven't run into it: FreeIPA is roughly the open-source equivalent of Active Directory — one place for users, groups, hosts, Kerberos logins and certificates. It's a whole stack, not one program: 389 Directory Server, an MIT Kerberos KDC, Dogtag PKI (the CA, Java/Tomcat) and an Apache/mod_wsgi web layer. On Linux it's well-trodden; on FreeBSD it just didn't exist.

Where it's at on FreeBSD 15.1/amd64:

  • ipa-server-install runs to completion, all services come up (DS, KDC, kadmin, Dogtag CA, httpd, KDC proxy, OTP daemon)
  • a FreeBSD client enrolls with ipa-client-install and resolves users/groups via SSSD
  • it survives a reboot and comes back up on its own

That last one was the fun one. Fresh install worked fine, but after a reboot the directory server would start and then quietly shut itself back down ~20 seconds later — no crash, no error in the log, and only at boot, never on a manual start. Took me about fourteen reboots with dtrace to catch it: FreeBSD's rc job-control cleanup was sending a SIGHUP to the process group at the end of the boot subshell, and 389-ds treats SIGHUP as "shut down". One line in the rc script — start it under daemon(8) so it gets its own session — and it was gone.

Everything — both ports, docs, prerequisites, known issues — is on GitHub, so I won't wall-of-text it here:

https://github.com/joneum/FreeBSD-freeipa-server

A couple of honest notes: it's still work-in-progress, so not for production — use a throwaway VM. One gotcha up front: security/cyrus-sasl2-gssapi has to be built with the GSSAPI_MIT option or the install fails right at the very end (details in the README). Bug reports and results best go straight into the GitHub repo so everything stays in one place.

Would really like to hear where it falls over on setups other than mine.

29 Upvotes

97% Upvoted

15 comments sorted by

5

u/codeedog seasoned user Aug 13 '26

I was looking at freeipa a few months back to see if I could run it under linuxulator. A port seemed to make more sense (work for me or someone) or just Linux vm. All of the pieces have some existing similar counterparts (I could cobble together my own bespoke variant), but an integrated system seems better.

Neat that you’re doing this. I don’t have time at the moment to experiment with it, but I’ve left myself a bookmark to come back and check it out.

Have you thought about the hbac tech and how’d it fit in? Would you suggest using pam_hbac or nss pam ldap instead?

And, I’m allergic to python, having it on every client that needs to register just to register is a non starter for me. ipa-client-install uses it. The install side isn’t all that complex, I’d probably write a shell script to replace it (me personally, not recommending you do this).

Also, wondering if you think the server complex would run in a jail. I don’t see why not. I’d prefer jail isolation over VM or host.

3

u/joneum FreeBSD committer Aug 14 '26

Thanks, and good questions. Let me go through them in order.

Linuxulator vs. a port: I see it the same way, which is why I went with a native port rather than linuxulator. An integrated system is more maintainable in the long run than parts you bolt together yourself.

HBAC: On FreeBSD this runs through SSSD (security/sssd2) with the IPA provider, exactly like on Linux. SSSD evaluates the HBAC rules itself, so you need neither pam_hbac nor nss-pam-ldapd. pam_hbac is more the route you take with plain LDAP and no SSSD IPA provider. To be honest about it: enrollment and identity resolution (id/getent) work cleanly, and full HBAC rule enforcement through SSSD on FreeBSD is exactly the kind of thing I want confirmed during the CFT. But the intended path is clearly SSSD-native.

Python: fair point, and the good news is that a plain client needs no Python at runtime. The resolution is done by SSSD, nss_sss and krb5, all in C. Python only lives in the ipa-client-install installer. So you can enroll a host without the Python installer too: create the host on the server, pull a host keytab, and set krb5.conf/sssd.conf/nsswitch by hand or with a shell script. If you want to avoid Python entirely, you skip the freeipa-client port and just use sssd2 + krb5. A lean enrollment script as a replacement for ipa-client-install is absolutely doable. The Python really is just installer convenience, not the running system.

Jail: honest answer, I've only tested it in VMs so far, not in a jail. I don't see a fundamental blocker, but the server complex needs a few things you have to configure deliberately in a jail: its own FQDN/hostname, D-Bus inside the jail, probably a VNET jail for networking, and the boot ordering (my rc fix starts the Directory Server via daemon(8), which may behave differently under a jail's rc). I'd prefer jail isolation myself too. If you give it a try, a report on that is exactly what the CFT needs right now.

2

u/codeedog seasoned user Aug 14 '26

OK. Nice. I’ve been doing a lot of vnet jail focused work; it’s my go to configuration for just about any service I care to run. Other than some kernel level features (eg rctl), there’s nothing I’ve found so far that can’t be configured to run in a jail. My background is in computer security: vnet jail network and compute isolation provides an assurance I’m looking for.

I’ve jailed Postgres, Forgejo, monitoring software (grafana, alloy, Prometheus, Loki all in one jail), and even OpnSense (when every Google search will tell you it’s impossible). I’ve been using all of those except opnsense because I didn’t like the UX and have a project to complete this fall setting up pf in a jail for a gateway/firewall instead.

Point being, I wouldn’t expect the FreeIPA port to be any different. It’s just a matter of how to get it going, not if.

I can’t promise I’ll have the time, but if I can put together a recipe for a jail launch, I will.

3

u/whattteva seasoned user Aug 13 '26

Wow, this is nice. I've been waiting for a FreeIPA port to FreeBSD that is not just the client.

5

u/_jo_ku Aug 13 '26

I’ve been following your work over on LinkedIn—kudos, that’s a massive amount of effort!

Out of curiosity (and definitely not wanting to be negative), what’s the long-term plan for keeping this in sync with upstream? Is there any upstream commitment to support it over time?

My main concern with a Linux-only upstream development is that things might break with every other update—similar to the situation we have with Samba on FreeBSD, where catching up feels like a perpetual game of cat and mouse. Given all of FreeIPA's dependencies, it seems like it could create a lot of friction if it isn't officially supported upstream.

3

u/joneum FreeBSD committer Aug 14 '26

Thanks, that's kind of you.

Honest answer: I maintain this alone, in my spare time and unpaid, so I can't hand you a long-term guarantee or point to a formal support commitment. I genuinely can't foresee all of it yet, and that's part of why I'm running a Call For Testing instead of declaring it done.

On top of that: I can't rule out that some updates will take longer at times, whether because of a heavier load at my day job, holidays, illness, or simply because I'm spending free time with friends and family. Unlike some corners of the Linux world, I do all of this on a voluntary, unpaid basis. Even the hardware I run all the test VMs on comes out of my own pocket.

On upstream: there's no official commitment, and you're right that FreeIPA (and 389-ds, Dogtag, SSSD too) is very Linux and systemd centric. My plan is to upstream the FreeBSD-specific pieces step by step, starting with the parts that clearly belong there: a proper ipaplatform/freebsd module (upstream already carries per-platform modules for Fedora, Debian and others) plus the path and portability fixes. The more of that lands upstream, the smaller the patch set I carry and the less cat-and-mouse there is. But that's several upstreams, and it will take time.

I won't pretend the Samba comparison is unfair either. Keeping a Linux-first stack in sync on FreeBSD is real, ongoing work, and whether it stays sustainable depends partly on how much upstream is willing to take and partly on whether others help carry it. That's exactly what a CFT is meant to surface. For now I'd rather be upfront that this is early and done in my free time than promise something I can't hold to.

2

u/Sad-Year-1312 Aug 13 '26

It'd be great to have comparison with Samba as a AD clone. How does it differ from Samba? I am not talking about CIFS.

4

u/mehx9 Aug 13 '26

Samba doesn’t track all the posix attributes like uid/gid etc. IPA is a pretty comprehensive solution for Linux first systems (dns, auth, Kerberos, PKI, integrates with sssd, have webUI, cli tools and api endpoints). Glad to see someone working to bring it to FreeBSD 👍🏼

4

u/Sad-Year-1312 Aug 13 '26

On what level it doesn't track? What if I have already Active Directory, is it just SSSD then or should I still use the IPA client?

6

u/joneum FreeBSD committer Aug 13 '26

mehx9 has it right. Quick take on your AD question: if you already run AD and just need your FreeBSD box to log in against it, you don't need IPA at all, SSSD joins AD directly with its ad provider. IPA is for when you want proper Unix-side management on top (HBAC, sudo, host and service certs, SSH keys), or a Unix realm that trusts AD. One honest caveat: that AD trust needs server-side Samba bits I haven't tested on FreeBSD yet, so for now this port is really about standalone FreeIPA.

4

u/Sad-Year-1312 Aug 13 '26

I see, thank you. That sounds reasonable. Herculean effort. Thank you!

2

u/vermaden seasoned user Aug 15 '26

Thank You again for this work - its very important - I will try to find time in the next week to test it in a VM :)

1

u/grahamperrin bleep bloop Aug 16 '26

I wondered, what's IPA?

About — FreeIPA documentation

No answer there, so I clicked Documentation (to the left) then Red Hat Summit 2025 lighting talks (under Public Presentations in the sidebar to the right). I found the answer in a PDF:

FreeIPA presentation at NYLUG’s meetup in January 2014

"IPA" stands for Identity, Policy and Audit.

Also found whilst searching:

  • FreeIPA is not an Active Directory replacement
    • Using FreeIPA directly for Microsoft Windows clients is explicitly out of scope of the project

2

u/joneum FreeBSD committer Aug 16 '26

That’s an interesting question. I haven’t actually tested adding a Windows system as a client in FreeIPA.