samba - Jun 2025 - both Samba-4.9.5 AD DC upgrade to Samba current (4.22.*) - questions

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

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
>

On Sun, 29 Jun 2025 23:26:40 +0200
Franta Hanzl?k <franta at hanzlici.cz> wrote:
> 
> 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?
> 
Using a temporary DC is for safety purposes only, you could just
replace the DCs one by one, the only thing you have to realise is that
even if the the replacement DCs use the same hostname and ipaddress,
they will be new DCs. In any case, non of the computers in your domain
care what hostname or ipaddress your DCs have, they will find them via
DNS.
> - 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? 
Yes, here is myself on a Unix domain member:

getent passwd rowland
rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash

I use the 'rid' backend and as long as you use the same 'idmap
config'
lines on all Unix domain members, you will always get the same IDS, not
that it matters, Samba will map your accounts to IDs on that system,
even if you use different ranges.

Think about it, if you do not add rfc2307 attributes, a user on a DC
will get an ID in the 3000000 range, on a Unix domain member they will
get an ID inside whatever 'DOMAIN' range you set in the smb.conf file
and on Windows, well they do not care, they use the SID (which is what
Samba is really using). They will all be the same user and Samba (and
Windows) knows who they are.
> 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
What POSIX parameters ?
The 'rid' idmap backend calculates Unix IDs from the RID
You can set the users home directory and shell with template lines in the
smb.conf file.

Anything else isn't really required.
> On the current old system we
> enter POSIX parameters manually, so some simplification or automation
> would be welcome...
With the 'rid' backend, you just create the user, after that it just
works.
> 
> 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.
In my opinion, the problem with Fedora is, they are not honest. The use
of MIT for the kdc on a Samba AD DC is experimental and redhat is on
record of saying there will never be Samba packages for RHEL that can
be provisioned as an AD DC, but they do not and will not tell their
users this.

You can easily switch to Debian, just install Debian 12 in a VM,
install Samba from bookworm-backports and you will get the latest Samba
version (4.22.2 at present), just join this and it will work.

Rowland

On 29 Jun 2025 at 22:26 +0100, Franta Hanzl?k <franta at hanzlici.cz>,
wrote:
>
> 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?
This would be fine, and because you have a backup of the VMs, you?re safe.
Demote the DC that does not have the FSMO roles.
>
> - 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...
If you use AD idmapping in your member servers, that?s fine, continue with it.
You can - however - safely remove the line from your DCs. Reasons explained in
the link.
>
> 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.
I?d use Debian, distro of choice for all things Samba.