On Sun, Jul 23, 2023 at 6:31 AM Alexander Bokovoy
<abbra(a)fedoraproject.org> wrote:
>
> On Суб, 22 ліп 2023, Neal Gompa wrote:
> >On Sat, Jul 22, 2023 at 5:09 PM Adam Williamson
> ><adamwill(a)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/Do...
> >>
> >> 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.
>
>
https://www.youtube.com/watch?v=6TMd9r2VngI
>
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]