[HN Gopher] Native FreeBSD Kerberos/LDAP with FreeIPA/IDM
___________________________________________________________________
Native FreeBSD Kerberos/LDAP with FreeIPA/IDM
Author : vermaden
Score : 106 points
Date : 2026-02-18 10:29 UTC (12 hours ago)
(HTM) web link (vermaden.wordpress.com)
(TXT) w3m dump (vermaden.wordpress.com)
| cullumsmith wrote:
| Nice. I run a very similar setup, but opted for a stack of
| OpenLDAP / MIT Kerberos / PowerDNS on my "domain controllers."
|
| OpenLDAP does multimaster replication and is the backend for DNS
| records and the Kerberos database.
|
| The hardest part was figuring out OpenLDAPs configuration syntax,
| especially the correct ldif incantations for things like nested
| group memberOf= queries, schemas, and ACLs. It's somewhat
| inscrutable... Nowadays an LLM could do it for you at least.
|
| At $job we use Linux / sssd, and I always found it super bloated
| and rather unreliable. It's nice coming home to FreeBSD and old
| boring stuff like pam_krb5 and nslcd. It just works.
|
| The "ipa" command provided by FreeIPA for managing
| users/groups/etc is super convenient though.
| whalesalad wrote:
| Would be highly interested in learning more about this setup
| particularly the PowerDNS integration.
| cullumsmith wrote:
| PowerDNS is an open-source DNS server that lets you store
| your DNS configuration in a variety of different backends,
| one of which is LDAP.
|
| For each of my "domain controllers, I run: OpenLDAP, an MIT
| Kerberos KDC, and a PowerDNS server. The KDC and PowerDNS
| both get their data from LDAP on 127.0.0.1, and LDAP changes
| are synchronized between all the nodes.
|
| This is convenient because you don't have to synchronize zone
| files on multiple hosts.
|
| I use custom /bin/sh-based config management system, but you
| can probably get the gist of it here:
|
| https://github.com/cullumsmith/infrastructure/blob/master/sc.
| ..
|
| https://github.com/cullumsmith/infrastructure/blob/master/fi.
| ..
| esseph wrote:
| In addition to this, for those of you running Proxmox it
| has PowerDNS integration.
| xorcist wrote:
| I don't think it's exactly the same thing as sssd is primarily
| a cache. You can use pam_krb5 on Linux too. But can you
| disconnect your FreeBSD laptop and work as normal from cache? I
| agree that sssd is quite finicky however, and I'd love a
| simpler alternative.
| cullumsmith wrote:
| You are correct, sssd has a ton of features (like basically
| replicating the entire domain locally and caching passwords
| so you can roam away from your corp network). If you need
| those things, you need sssd.
| radarsat1 wrote:
| > The hardest part was figuring out OpenLDAPs configuration
| syntax, especially the correct ldif incantations ..
|
| As a long time Linux user on personal machines, I found myself
| for the first time a couple of years ago needing to support a
| small team and given them all login access to our small
| cluster. I figured, hey it's annoying to coordinate user ids
| over these machines, I should just set up OpenLDAP.. little did
| I know.. honestly I'm pretty handy at dealing with Linux but I
| was _shocked_ to discover how complicated and annoying it was
| to set up and use OpenLDAP with NFS automounting home
| directories.
|
| For the first time in my life I was like, "oh this is why
| people spend years studying system administration.."
|
| I did get it working eventually but it was hard to trust it and
| the configuration GUI was not very good and I never fully got
| passwd working properly so I had to intervene to help people
| change their passwords.. in the end we ended up just using
| manually coordinated local accounts.
|
| The whole time I'm just thinking, I must be missing something,
| it can't be this bad.. I'm still a bit flabbergasted by the
| experience.
| paffdragon wrote:
| Hah, what a coincidence, just started to look into yesterday how
| do I setup LDAP/OIDC on FreeBSD and today I was going to try
| FreeIPA or Keycloak. Thanks for sharing.
| vermaden wrote:
| I also covered Keycloak on FreeBSD in the past - here:
|
| - https://vermaden.wordpress.com/2024/03/10/keycloak-on-
| freebs...
|
| Hope that helps.
|
| Regards,
|
| vermaden
| ipython wrote:
| Don't forget to delete the keytab file from the ipa server!
| Otherwise anyone will be able to unauthenticated download that
| file and impersonate that host principal
|
| Better yet you'll want to encrypt that file in some way when
| transferring it
| vermaden wrote:
| Good point - gonna add a notice about that - thank You.
| zokier wrote:
| I feel this is one of the weaknesses of Linux/unix ecosystem. The
| freeipa/sssd/nss/pam/krb/ldap/dns (+keycloak/samba/...) etc stack
| is just incredibly byzantine. I'm sure it is technically very
| capable in the right hands, but to me it feels like intractable
| mountain of things and worst of all the failure modes are pretty
| bad; you can accidentally leave security holes or alternatively
| lock yourself out.
| ipython wrote:
| Yes. And Microsoft Active Directory has integrated this stack
| with an easy to use graphical interface for almost 30 years
| now.
| bzzzt wrote:
| Active directory is dying along with local computer networks.
| Microsoft is pushing customers to Entra (formerly Azure
| Active directory). Modern, hybrid AD is not easy to use and
| difficult to manage.
| esseph wrote:
| > dying along with local computer networks
|
| I have seen the exact opposite, with people moving to
| things like jumpcloud, keycloak, authentik, etc.
| amaccuish wrote:
| Jumpcloud is SaaS.
| esseph wrote:
| Yes, but it's not Microsoft Active Directory or Entra,
| which was my point.
| bzzzt wrote:
| Those are all apps running in the cloud. I meant the
| classic Windows AD company LAN like solutions where the
| clients, server and network are tightly coupled.
| esseph wrote:
| > Those are all apps running in the cloud.
|
| Authentik and others can be deployed as docker containers
| that can be deployed any way you wish.
|
| > I meant the classic Windows AD company LAN like
| solutions where the clients, server and network are
| tightly coupled.
|
| In any mixed environment these days of Windows PCs,
| MacOS, and Linux, yeah, you can use a SaaS like jumpcloud
| with support for all of them, or you can integrate them
| into the ldap/kerb backend of your choice. Bonus points
| if your network devices are using RADIUS auth to the same
| identity source.
| jabl wrote:
| There's https://himmelblau-idm.org/ for a Linux client for
| Entra. Haven't tried it myself though.
| dijit wrote:
| Doesn't FreeIPA work with EntraID? I used to use it with
| Exchange and it worked pretty well.. (or, as well as any
| non-microsoft product that has to intergrate with
| Microsoft products at least).
| bzzzt wrote:
| Looks nice, all it needs is an OSS server now ;)
| dijit wrote:
| This is 100% the current situation, and it's worth
| mentioning because clearly you have a finger on the pulse
| here - and that needs to be stated for others.
|
| But, I wonder if Microsoft might reverse their stance on
| EntraID being SaaS; with the handwringing about sovreignty
| from Europe.
|
| Back when "the deal" was made with Microsoft to basically
| embed itself into the digital ecosystem of every
| government, major institution and company in Europe: it was
| not the case that a member of the european parliament could
| have their mail disabled arbitrarily by Microsoft- such a
| thing was _technically_ possible through a lot of hoops but
| it was significantly less feasible.
|
| If Microsoft was to reverse course then I'm sure it would
| stop all the handwringing, even if people would continue to
| use the EntraID product in reality.
| bzzzt wrote:
| I don't see Microsoft backing down from their SaaS push:
| it's necessary for authentication and authorization in
| all their Office 365 (or whatever it's called now)
| applications, also on platforms not running Microsoft
| clients. Beside that Entra is an OIDC server which makes
| it possible to integrate other SaaS applications in a
| domain which is near impossible to do if you only have
| local authentication.
|
| Of course, you can still run local AD which synchronizes
| with Entra, but that means you get the worst of both
| worlds: you are paying for the cloud software but still
| have to manage your own servers.
| ElectricalUnion wrote:
| Ideally you want to run all those trusted (read: security
| critical, if compromised entire system is no longer
| trustworthy) processes on separated and audited machines, but
| instead busy people end up running them all together because
| they happen to be packaged together (like FreeIPA or Active
| Directory), and that makes it even harder to secure them
| correctly.
| tremon wrote:
| There's a very good reason to package these things together
| on the same machine: you can rely on local machine
| authentication to bootstrap the network authentication
| service. If the Kerberos secret store and the LDAP
| principal store are on different machines and you need both
| to authenticate network access, how do you authenticate the
| Kerberos service to the LDAP service?
| Nextgrid wrote:
| It's also a ton of security-sensitive code that parses
| untrusted data in a memory-unsafe language.
| nimbius wrote:
| There used to be a time in history when a system administrator
| had to know all this shit in order to keep their job. I guess
| nowadays devops just means dev as we furiously pump tokens into
| the AI Wurlitzer whenever we dont know how to do something and
| hope it doesnt gaslight us into deleting prod.
|
| - Freeipa is Linux AD, includes DNS, dogtag, and OpenLDAP.
|
| - SSSD is how linux machines authenticate with a central
| directory. this includes AD.
|
| - nss is the order of operations in which the system attempts
| lookups against various directories for services.
|
| - pam is the subsystem of authentication in linux.
|
| - kerberos is a ticket based authentication system started by
| MIT and popularized by Microsoft.
|
| - ldap is a directory for information and authentication data
|
| - DNS should not need an explanation.
|
| Active Directory is the exact same byzantine architecture, the
| only reason you dont complain about it is because Microsoft has
| hidden nearly every meaningful internal from you with fun
| buttons and dropdowns like a childs toy.
|
| Make no mistake, when it breaks it is much more cataclysmic in
| its complexity. major multinational corporations can spend
| weeks with external consultants and even Microsoft themselves
| trying to debug it. Most failure modes result in rebuilding the
| entire directory from scratch out of the sheer futility of
| trying to recover anything. things as simple as an OS update
| can cause the complete failure of the directory, replication,
| kerberos key subsystem, or even the ADUC tool you use to
| interface with any of this. Most of the time your only solution
| is to wait for MS to release a fix.
|
| FreeIPA isnt complete. it doesnt include things like group
| policies or account expiration but its infinitely easier to
| debug. its individual components are well documented and offer
| standalone debug and trace features. most if its components
| have existed longer than their competitive Microsoft offerings,
| or at very least vastly outscale and outperform them.
|
| Kubernetes is just as complex, but cloud providers will happily
| bill you by the nanosecond for the gentle equivalent of
| Microsofts buttons and dropdowns. Microsoft will gladly bill
| you for "cloud" based AD. You can just as easily deploy local
| users in ansible.
| p_ing wrote:
| Dang, your failure modes certainly are extreme. What
| companies actually performed a from-scratch rebuild because
| they failed to take a backup or thought "today's thursday,
| it's too complicated to restore!"?
|
| If an "OS upgrade" nukes your directory, that means you're
| running a single DC. The question is... why would you do
| that?
| linksnapzz wrote:
| _There used to be a time in history when a system
| administrator had to know all this shit in order to keep
| their job. I guess nowadays devops just means dev as we
| furiously pump tokens into the AI Wurlitzer whenever we dont
| know how to do something and hope it doesnt gaslight us into
| deleting prod._
|
| Thanks, that sentence made my day.
| StopDisinfo910 wrote:
| It's always been awful. OpenLDAP by itself is already
| attrocious and a pain to make work.
|
| I have always been convinced it was on purpose. It's the point
| where you were supposed to decide paying Redhat is actually a
| good idea and nowadays it pushes towards a cloud based
| authentication solution you can integrate.
|
| Realistically, who has any interest in fixing the mess?
| doctorpangloss wrote:
| > Realistically, who has any interest in fixing the mess?
|
| Okta is a multi billion dollar company, there is a lot of
| venture opportunity in this space.
| StopDisinfo910 wrote:
| I think that's actually directly in agreement with what I
| said. Okta built their own thing on the side without
| touching the Linux stack and is very happy for you to turn
| to them. So did Authentik actually.
| xorcist wrote:
| > you were supposed to decide paying Redhat
|
| Fwiw, all Red Hat LDAP products are based on 389DS because
| they thought OpenLDAP had too many pain points or something.
| evanjrowley wrote:
| Microsoft is pushing everyone onto Entra. There are so many
| exploits for AD but few for Entra.
|
| Tenable has been pushing an internal initiative to eliminate
| all AD use. This action speaks volumes considering they
| acquired an AD security company and sell a product specifically
| designed to secure AD.
|
| The consequences of a compromised AD domain are drastic. We
| should not try to build the same vulnerabilities into Linux
| environments, but it's undeniable there is value in leveraging
| FreeIPA et al. to interoperate with legacy environments.
| Smar wrote:
| LDAP Kerberos 5 SSSD is pretty easy to configure and more or
| less maintenance free for a small set of servers and users. By
| my personal experience.
|
| The costs usually come from complexity: every new user needs
| its credentials, guidance to services and help in error
| situations. New services need to be integrated to existing
| systems. But those won't go away, be the system anything.
| ptx wrote:
| > _this new method is possible to work because FreeBSD switched
| from Heimdal Kerberos implementation to MIT Kerberos in FreeBSD
| 15.0-RELEASE ... and I am really glad that FreeBSD finally did
| it._
|
| What was the problem with Heimdal? The FreeBSD wiki says they
| used an old version, but why not upgrade to a newer version of
| Heimdal instead of switching to an entirely different
| implementation?
| p_ing wrote:
| This [0] may provide a hint. Heimdal was developed outside of
| the US and not subject to export restrictions, unlike MIT. So
| perhaps in the beginning it wasn't the package of choice to
| begin with.
|
| And this [1] says for interoperability reasons.
|
| [0] https://docs-
| archive.freebsd.org/doc/11.1-RELEASE/usr/local/...
|
| [1] https://freebsdfoundation.org/project/import-mit-kerberos-
| in...
| cryptonector wrote:
| I don't think that has anything to do with FreeBSD's choice
| of MIT Kerberos or Heimdal.
| p_ing wrote:
| Well, except the FreeBSD Foundation explicitly says MIT was
| chosen for interoperability.
|
| Are you disputing the FreeBSD Foundation document?
| cryptonector wrote:
| Because we (Heimdal) need to make a release, darn it. I'm going
| to cut an 8.0 beta within a week or two.
|
| Basically, an 8.0 release is super pent up -- years. It's got
| lots of very necessary stuff, including support for the
| extended GSS-API "cred store" APIs, which are very handy. Lots
| of iprop enhancements, "virtual service principal namespaces",
| "synthetic client principals", lots of PKINIT enhancements,
| modern public key cryptography (but not PQ), etc.
|
| The issue is that the maintainers (myself included) have been
| busy with other things. But the pressure to do a release has
| ramped up significantly recently.
| lukeh wrote:
| Also things like support for GSS-API pre-authentication
| mechanisms (so, you can use an arbitrary security mechanism
| such as EAP to authenticate yourself to the KDC), the new
| SAnon mechanism, pulling in some changes from Apple's fork,
| replacing builtin crypto with OpenSSL, etc. Lack of release
| has been typical OSS lack of resources: no one is paid to
| work on Heimdal full time.
| blacklion wrote:
| It is pity, we need Linux to tun open source software like
| FreeIPA/IDM.
|
| I want to deploy domain at my home lab, but there are only
| FreeBSDs and Windows (client versions, on desktops and
| laptops)... I don't want to install Linux.
| sidkshatriya wrote:
| First, I read (article referred to in blog post):
|
| https://blog.hofstede.it/integrating-freebsd-15-with-freeipa...
| [1] .
|
| _Only then_ I read
| https://vermaden.wordpress.com/2026/02/18/native-freebsd-ker...
| [2]
|
| [1] is more high level. [2] is a bit more detailed.
| vermaden wrote:
| I hope I was clear enough that credit for the solution goes to
| Christian Hofstede-Kuhn (Larvitz).
|
| I treat my blog also as a place where I keep and maintain my
| FreeBSD documentation/information.
|
| So there are several motivations for this:
|
| - Keep and maintain personal version with more code snippets
| that I can copy/paste fast.
|
| - More detailed commands and outputs.
|
| - Some additional improvements that may be useful - like local
| console login.
|
| Hope that helps.
| throw0101a wrote:
| Perhaps worth noting that keytab files often need to be refresh
| as TGTs expire; handy utility to do that:
|
| * https://www.eyrie.org/~eagle/software/kstart/
|
| * https://www.freshports.org/security/kstart/
| scottylogan wrote:
| The keytabs don't need to be refreshed, but the ticket caches -
| where the TGTs are stored - do.
| amaccuish wrote:
| The FreeIPA documentation could be made a bit clearer, so many
| "obsolete" pages showing in search.
|
| To my question, does anyone know if FreeIPA now supports
| integration with Samba including password auth for non domain
| members? Or is it still limited to Kerberos?
| beagle3 wrote:
| Is there a simpler system for a small local network? For my home
| lab use case, it is almost sufficient to rsync
| /etc/{passwd,group,hosts,.....} - I manually sync them because
| changes are few and far between.
|
| I wanted to set up a central authority - i don't care about multi
| master or even resilience to failure in that central authority.
|
| But even a small setup is relatively complicated. I remember yp
| setup in the early '90s looked complicated but it is a piece of
| cake compared to modern systems. They provide a lot, but they
| don't scale down - and it feels to me that they are complicated
| much more than is required for their feature list.
|
| Take LDAP, for example - it is only "lightweight" compared to the
| thing it replaced. But it is ridiculously complicated for what it
| is. It is designed for a bandwidth-scarce, intermittent
| connection world; for a modern world, I'd just put it all in an
| SQLite database and rsync it all over the place (and use remote
| queries, the replicas only used for offline validation).
| jimmyswimmy wrote:
| I would love a simpler system. Everything is pointing me back
| towards using a Windows server eval instance for this, which
| feels like a pretty heavy way to manage a bunch of alpine
| containers. FreeIPA, openLDAP and I think the other one I tried
| was Keycloak - all were more trouble to configure than they
| were worth. I'm shocked it never occurred to me to just rsync
| the passwd files, or SCP them using an update service. Would
| love a nicer way to manage users across a very small network
| without needing so much complexity as these other services.
| locusofself wrote:
| 8 years ago or so I had a job that necessitated doing a bunch of
| LDAP integrations and I tried FreeIPA, openLDAP and others. It
| was such a pain. OpenLDAP (slapd) was actually configured
| using... LDAP. Yes, you configured an LDAP server using it's own
| protocol. It was not good. My fading impression of FreeIPA is
| that it had some nice things going for it, but it wasn't nearly
| as lightweight or friendly towards automation, it felt more like
| setting up a windows domain controller and clicking through a
| webUI to set things up.
| inejge wrote:
| > Yes, you configured an LDAP server using it's own protocol.
| It was not good.
|
| It's still possible to configure OpenLDAP via the slapd.conf
| file. The old roadmap called for ditching configuration file
| support in 2.5 IIRC, but it proved hugely unpopular so the file
| works to this day. The new configuration style is mainly useful
| for live updating of access rules and indexing.
___________________________________________________________________
(page generated 2026-02-18 23:00 UTC)