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.
> 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.
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.
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.
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.
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?
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.
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.
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
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).
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.
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.
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.
> 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.
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.
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?
> 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?
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.
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.
cullumsmith|12 days ago
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.
radarsat1|11 days ago
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.
xorcist|11 days ago
whalesalad|12 days ago
zokier|12 days ago
evanjrowley|12 days ago
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.
ipython|12 days ago
StopDisinfo910|12 days ago
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?
nimbius|12 days ago
- 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.
Nextgrid|12 days ago
Smar|11 days ago
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.
ipython|12 days ago
Better yet you’ll want to encrypt that file in some way when transferring it
vermaden|12 days ago
vermaden|11 days ago
sidkshatriya|12 days ago
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|12 days ago
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.
beagle3|11 days ago
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|11 days ago
blacklion|12 days ago
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.
vermaden|11 days ago
locusofself|11 days ago
inejge|11 days ago
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.
paffdragon|12 days ago
vermaden|12 days ago
- https://vermaden.wordpress.com/2024/03/10/keycloak-on-freebs...
Hope that helps.
Regards,
vermaden
amaccuish|12 days ago
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?
amaccuish|7 days ago
throw0101a|12 days ago
* https://www.eyrie.org/~eagle/software/kstart/
* https://www.freshports.org/security/kstart/
scottylogan|11 days ago
ptx|12 days ago
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?
cryptonector|11 days ago
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.
p_ing|11 days ago
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...
unknown|12 days ago
[deleted]
poketdev|12 days ago
[deleted]