[Samba] both Samba-4.9.5 AD DC upgrade to Samba current (4.22.*) - questions

[Luis Peromarta]

Rfc2307 is not needed in DCs even if you use it for AD idmapping in your member server.

See linked page for explanations and what it implies for a DC.
On 29 Jun 2025 at 22:26 +0100, Franta Hanzlík <franta at hanzlici.cz>, wrote:

> On Sun, 29 Jun 2025 19:30:00 +0100
> Luis Peromarta via samba <samba at lists.samba.org> wrote:
>
>
> > Hi there.
> >
> > The Oracle has already spoken, (@Rowland) I will give you some links:
> >
> > This is what I would do:
> >
> > First, there is a chance you may need to do this in 2 stages as 4.9 to 4.22 may be a bit too extreme.
> >
> >
> >
> > 0.- Back up both VMs, just in case.
> >
> > 1.- Do a good check on the DCs:
> >
> > http://samba.bigbird.es/doku.php?id=samba:dc-maintenance
> >
> >
> > 2.- Install and join new DC using Debian 12, you will need a new name for the machine:
> >
> >  http://samba.bigbird.es/doku.php?id=samba:aditional-dc
> >
> > If you get errors with this join, chances are you may need to get an intermediate version (Debian 11 and Samba 4.13). If so, restore VMs from backup and try Debian 11.
> >
> > 3.- All going well you have now 3 DCs. Transfer the FSMO roles to the new one:
> >
> > http://samba.bigbird.es/doku.php?id=samba:fsmo-roles
> >
> > 4.- Demote one of the older DCs:
> >
> > http://samba.bigbird.es/doku.php?id=samba:demote-dc
> >
> > 5.- Install an additional new DC as (2)
> >
> > 6.- Demote the other, older DC as (4)
> >
> > 7.- Once all has been tested with Samba 4.17, upgrade to 4.22 using back ports:
> >
> > Using back ports:
> >
> > http://samba.bigbird.es/doku.php?id=samba:installing-from-backports
> >
> > Uppgrade:
> >
> > http://samba.bigbird.es/doku.php?id=samba:upgrade-sama
> >
> > 8.- Once all done, check you only have on entry for PDC Emulator role:
> >
> > http://samba.bigbird.es/doku.php?id=samba:fsmo-roles
> >
> >
> >
> > Note: If you are using "idmap_ldb:use rfc2307 = yes” I recommend you don’t.
> >
> > http://samba.bigbird.es/doku.php?id=samba:no-need-for-use-rfc2307
> >
> > On 29 Jun 2025 at 18:31 +0100, Franta Hanzlík via samba <samba at lists.samba.org>, wrote:
> >
> > > > We are preparing to upgrade our two Samba AD DCs during this school
> > > > holidays. Both current DCs are x86_64 VMs with Samba 4.9.5, AD schema
> > > > = 47 (Server 2008R2), there is one AD domain.
> > > > We expect to upgrade to Samba 4.20.* or 4.22.* and AD schema to current
> > > > Server 2019 or 2022.
> > > >
> > > > Can you please advise on the optimal upgrade procedure, and possibly
> > > > give some general recommendations and warnings about possible issues?
> > > >
> > > > According to the Samba Wiki at
> > > > https://wiki.samba.org/index.php/Upgrading_a_Samba_AD_DC
> > > > , it seems that this procedure might work:
> > > >
> > > > - on FSMO DC, backup domain (samba-tool domain backup online ...)
> > > >
> > > > - demote non-FSMO DC (samba-tool domain demote ...), shutdown VM
> > > >
> > > > - run new VM with actual Samba-4.22.x DC installed, with same hostname,
> > > > realm,... as had previously removed machine.
> > > >
> > > > - join to domain (samba-tool domain join ...)
> > > >
> > > > - start Samba and run AD replication status and Samba AD DC database
> > > > check (samba-tool drs showrepl ... / samba-tool dbcheck ...)
> > > >
> > > > - transfer FSMO role to newly joined DC (samba-tool fsmo transfer...)
> > > > (is it really needed? What about seizing a FSMO Role at the whole end?
> > > > - but Wiki say FSMO transfer is recommeded before seizing)
> > > >
> > > > - demote former FSMO, stop Samba and shutdown this old VM
> > > >
> > > > - run another new VM with actual Samba-4.22.x DC prepared, with same
> > > > hostname, realm,... as had previously removed former FSMO.
> > > >
> > > > - join it to AD, start Samba, check replication and DB status, maybe
> > > > transfer FSMO here again..(or seize FSMO here?)
> > > >
> > > > - upgrade AD schema version (samba-tool domain schemaupgrade...) to
> > > > value 88
> > > >
> > > >
> > > > Apart from the fact that I am not sure that the above procedure is correct
> > > > and optimal, there are still some ambiguities, e.g.:
> > > >
> > > > - already mentioned above - can there be no server FSMO role defined
> > > > anywhere (during the upgrade)? (and then seizing if at final end)
> > > >
> > > > - Since Samba-4.9.5 supports a higher (but experimental) schema 69
> > > > (Server 2012R2), wouldn't it be better to upgrade the AD schema to this
> > > > level on the old DCs (and at end only do a schema upgrade 69 -> 88)?
> > > > --
> > >
> > --
> >
>
> Hello Luis, Peter and Rowland,
> many thanks for quick response, valuable advice and references to
> samba.bigbird.es (it will take some time to absorb it all)!
>
> I have a small addition to this:
>
> - By using the demotion of the old DC and its permanent removal from the
> network and subsequent inclusion of a new VM with the same hostname, IP,
> etc., I aimed to achieve the same external characteristic and behavior
> after the upgrade as the original system had. And I would probably not
> need to use a temporary VM - the new DC would replace the old one 1:1.
> Or am I wrong?
>
> - Both VMs are small, serving only as DCs, no fileserver, printserver,
> etc. And yes, on the current (old) system we use rfc2307 (so on each DC
> there is "idmap_ldb:use rfc2307 = yes" in smb.conf, and on the two Samba
> fileservers is "idmap config DOMAIN:backend = ad" in smb.conf).
> rfc2307 is used for Linux clients, their POSIX attributes such as UID,
> GID, homedir. I thought until now that if Linux clients also authenticate
> to Samba AD, then it is necessary to use rfc2307.
> Are you saying it is different, that rfc2307 can be canceled?
> The "rid" idmap backend will then be used on the fileserver instead of ad?
> And will tools like RSAT on Windows or samba-tool on Linux also allow
> us to enter POSIX parameters? Or are they assigned somehow automatically?
> On the current old system we enter POSIX parameters manually, so some
> simplification or automation would be welcome...
>
> Regarding using Debian distro - we have been using Fedora for a long time
> now because we know it. And we compile Samba packages for DC ourselves,
> with Heimdal Kerberos (Fedora has MIT, I'm not sure how suitable it is
> for production deployment, I think it is still marked as experimental).
> I don't know if switching to Debian would cause some confusion and damage,
> when it will be new for us. IMO there will not be much difference in
> functionality, although support in Debian is probably greater today than
> in Fedora.
> --
> Thanks in advance, Franta Hanzlik
>