[Samba] Upgrading from Samba 4.8.2 to 4.15.5
mfoley at novatec-inc.com
Mon Jan 30 03:14:39 UTC 2023
On 1/29/2023 2:25 PM, Rowland Penny via samba wrote:
> On 29/01/2023 18:58, Mark Foley via samba wrote:
>> I am torn between using Heimdal and MIT. On the one hand, I really
>> like to use the packages supplied by the distro with as little
>> "customization" as possible, which in my case would be MIT. On the
>> other hand, my initial DC deployment using Slackware 14.1 back in
>> 2014 apparently did use Heimdal. And it appears that Heimdal is the
>> recommended kerberos by Samba.
> I can only advise, whether you follow my advice is up to you.
> From my understanding, Samba when trying to emulate an AD domain tried
> to use MIT for the DC's (note: it is only relevant on the DC's what
> kerberos is used, on the clients you can use either), but there were
> lots of problems. Not sure when Heimdal came into the mix, but it was
> soon chosen as the kerberos for the KDC, though work carried on to
> attempt to use MIT instead.
> If you use a Heimdal based Samba, then everything is expected to work
> (bugs allowing), but there will be problems using a MIT based Samba,
> that is why it is marked 'experimental'
> My advice would be, if you are going to continue to use Slackware,
> build Samba yourself using the builtin Heimdal.
>> For reasons explained earlier, include not using the
>> --dns-backend=BIND9_FLATFILE which is apparently obsoleted, I am
>> going to attempt to set up another DC using the latest Slackware 15.0
>> distro. I will find out how to transfer all the FSMO roles to this
>> new DC, then decommission the old one.
> Ah, that I can help you with, Very easy, just use 'samba-tool fsmo
>> I will go ahead and attempt to use the Heimdal kerberos if possible.
>> However, the instructions
>> just start with, "Set the following settings in your Kerberos client
>> configuration file /etc/krb5.conf", nothing about choosing which
>> kerberos. Before I get too deep into this, how do I specify using
>> Heimdal on a system that comes with MIT?
> As I said, if you build Samba yourself, it should just build with
> Heimdal, you have to use an explicit './configure' option
> (--with-experimental-mit-ad-dc) to use MIT.
Just to clarify, when you say "build Samba yourself" you mean basically
uninstall the distro's Samba and download sources, presumably from
build/install that, right?
> The distros that supply Samba AD DC packages that use MIT, must be
> using that option, but they do not seem to tell anyone that their
> packages are classed as experimental when it comes to provisioning an
> AD domain.
As I said, my "plan" is to created a 2nd DC with all the latest stuff,
then decommission the old DC. But, having never run more than one DC I
1. I assume the purpose of a 2nd (or 3rd ..) DC is as backup in case
something happens to the "master". Microsoft says, "In a single-master
model, only one DC in the entire directory is allowed to process
updates." Given that, it seems I must be mistaken that other DCs can
"take over" for a failed "master" unless it "seizes" the fsmo roles. So
then, what is the purpose of having more than one DC?
2. Let's say I get the new DC up and joined (I'll name it DC1), and I
transfer FSMO roles and demote the old DC (named MAIL). Does
transferring FSMO roles automatically fix-up Group Policies? For
example, the "Folder Redirection" group policy specifies "Root Path:
\\mail.hprs.local\Users". Would that get changed to
"dc1.hprs.local\Users" or would I have to manually change any GPOs, etc.
to reflect the new master DC's CN host?
3. In referring to a dead or broken DC from which FSMO roles were
seized, the wiki
says, "It is very important that the old DC will never be connected to
the network again". This is a bit scary as I like a way back, but I
suppose if something goes badly wrong after transfering FSMO roles, and
the old DC is still functionable, I can transfer FSMO roles back to it,
More information about the samba