[Samba] Upgrading from Samba 4.8.2 to 4.15.5

[Mark Foley]

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 
> transfer'
>
>>
>> I will go ahead and attempt to use the Heimdal kerberos if possible. 
>> However, the instructions
>> https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory#Kerberos 
>> 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 
https://download.samba.org/pub/samba/samba-latest.tar.gz, and 
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.
>
> Rowland
>
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 
have questions.

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 
https://wiki.samba.org/index.php/Transferring_and_Seizing_FSMO_Roles 
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, 
right?

Thanks --Mark