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.
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:
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 is eliminating all Active Directory use, even when they acquired a company and sell a product specifically designed to secure Active Directory.
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 interoperable with legacy environments.
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.
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).
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.
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.
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.
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.
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?
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.
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?
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?
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.
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
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.
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?
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.
> 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?
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.
Would be highly interested in learning more about this setup particularly the PowerDNS integration.
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...
In addition to this, for those of you running Proxmox it has PowerDNS integration.
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.
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.
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 is eliminating all Active Directory use, even when they acquired a company and sell a product specifically designed to secure Active Directory.
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 interoperable with legacy environments.
Yes. And Microsoft Active Directory has integrated this stack with an easy to use graphical interface for almost 30 years now.
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.
There's https://himmelblau-idm.org/ for a Linux client for Entra. Haven't tried it myself though.
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).
Looks nice, all it needs is an OSS server now ;)
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.
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.
> dying along with local computer networks
I have seen the exact opposite, with people moving to things like jumpcloud, keycloak, authentik, etc.
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.
Jumpcloud is SaaS.
Yes, but it's not Microsoft Active Directory or Entra, which was my point.
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.
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?
It's also a ton of security-sensitive code that parses untrusted data in a memory-unsafe language.
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.
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?
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?
> 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.
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.
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
Good point - gonna add a notice about that - thank You.
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.
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?
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.
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
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/
> 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?