On Няд, 23 ліп 2023, Neal Gompa wrote:
On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy abbra@fedoraproject.org wrote:
On Суб, 22 ліп 2023, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-07-22 at 21:43 +0300, Alexander Bokovoy wrote:
On Суб, 22 ліп 2023, Adam Williamson wrote:
On Sat, 2023-07-22 at 06:31 -0400, Neal Gompa wrote: > > > > What I intend after that is that we will be OK with releasing so long > > as the automated tests against Samba AD pass, but if anyone decides to > > manually test against Microsoft AD and finds a bug, that can > > potentially be a blocker. But we will not block the release on making > > sure Microsoft AD has been tested. > > > > Does this sound like a decent solution to everyone? Thanks! > > Does that mean that we will also have tests for setting up and using > Samba AD from Fedora? Because if we're going to block on client > connectivity on Samba AD, I think we should also block on Samba AD > from the server side too.
It means we'll have a test, but as things stand, failures of it won't be blocking, because "work as a Samba AD server" is not in the criteria.
You could, of course, propose a criterion change and we could debate it, though I think that might be a bit of a stretch - we already block on one domain server technology which is more in our ecosystem. Who's going to be the "throat to choke" for Samba AD server functionality if it breaks?
The same people who are responsible for 'FreeIPA server functionality if it breaks', for years.
We chose to have FreeIPA and Samba AD with MIT Kerberos as our domain controller technologies in Fedora more than a decade ago, we committed to develop them through Samba and FreeIPA upstreams, we keep doing so. Please watch our talk at SambaXP'23: 'Samba AD / MIT Kerberos: path out of experimental'.
https://www.youtube.com/watch?v=0_cdYuIYw0o
As I said, we already committed to this work for more than a decade ago in Fedora. We first announced productization of Samba AD DC with MIT Kerberos in Fedora 27 in 2017, this was a milestone which went into Fedora 27's release notes: https://docs.fedoraproject.org/en-US/fedora/f27/release-notes/sysadmin/Domai...
Thanks. I didn't realize it had that status.
If you team is happy to stand behind Samba AD in the same way it stands behind FreeIPA, I'd have no problem at all with it being release- blocking, if the WG wants to do that.
I think we'd be comfortable with that. The main issue right now is a lack of official Fedora documentation for setting this up that we could support it with.
To be honest, I'd hoped for a long time that Samba AD would become part of the FreeIPA setup. Sadly, it hasn't so far. :(
That is not a plan and it never was. FreeIPA works just fine with Samba AD over forest trust.
If you want to get a grasp over how complex things are, watch wonderful talk by Nadia who spent a good part of the past decade trying to make OpenLDAP backend for Samba AD.
Even if it was a forest trust, that doesn't mean that the IPA installer couldn't just set all that up with Samba AD all in one go, and the FreeIPA admin UI could expose Samba AD stuff.
That's not how it works. Samba AD and FreeIPA domain controllers cannot be set up on the same host. They conflict on multiple layers: there are incompatible LDAP schemas, different storage databases, same ports used by different components and so on.
Fundamentally, there is no need to make it working this way either. Samba AD serves Windows clients in the first place and Windows clients have certain expectations to how domain controllers operate. FreeIPA is isolated from those semantics by moving across to a separate forest, which means we only need to follow a very limited set of rules there as Windows clients will talk to their own domain controller and ask it to rely requests to a foreign domain controller if needed.
We plan to reuse some of the common technology, though. For example, ISC BIND project considers to make their database layer API private and doesn't expose it anymore[1]. This will affect both bind-dyndb-ldap and Samba AD DNS backends in future. We are looking at a common solution to those problems.
[1] https://www.isc.org/blogs/bind-architecture-25-years/