[Samba] Upgrading from Samba 4.8.2 to 4.15.5

[Mark Foley]

On 1/30/2023 2:48 AM, Rowland Penny via samba wrote:
>
>
> On 30/01/2023 03:14, Mark Foley via samba wrote:
>>>
>> 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?
>
> Yes, you can specify where the files are placed (by setting various 
> 'switches' in ./configure) or just leave it up to ./configure, in 
> which case everything will end up in /usr/local/samba
>
>>>
>> 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.
>
> My question has to be, why haven't you run more than one DC ? Running 
> multiple DC's gives you failsafe capabilities, you would have to have 
> a really catastrophic failure that took out all your DC's. At the 
> moment, you seem to have all your eggs in one basket.
>
>>
>> 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?
>
> Every DC holds your database, user, groups, computers etc and every DC 
> has the capability to hold FSMO roles. If something goes wrong with 
> one DC, it can quickly be replaced, even if it holds any FSMO roles.
> There is no concept of 'master' in AD, you can freely transfer the 
> FSMO roles (the only real difference) to any 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?
>
> I have to be honest here, I do not use GPO's so I am unsure of this, 
> but I would presume that to be the case, I am sure someone will 
> correct me if I am wrong.
>
Well, the domain members in our office are all Windows computers and 
(unfortunately) make extensive use of Group Policies, from redirected 
folders to remote access to MS Office Trust Center, to a plethora of 
other group policies. Frankly, I really dislike the Group Policy 
construct. Linux and Mac don't have such a thing and are fundamentally 
more secure than Windows. I think Group Policies are MS's way of trying 
to plug security holes in their swiss-cheese OS, yet hackers still 
easily break in. Don't get me started on my Windows soap-box! The point 
is, I would need for any additional DC to be able to automatically get 
all Group Policies, and point them to itself should something happen to 
what I've been calling the "master" DC. Even the time sync function 
explicitly specifies a 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?
>
> That was written in the context of a multiple DC domain and where a DC 
> had failed in such a way that it had to be removed. What you have to 
> understand is, once a DC is demoted, it is removed from AD and if you 
> then start the 'demoted' DC again, it will not be a member of the 
> domain and will not be able to take part in the domain, though it will 
> likely try. Even worse would be were a new computer is given the old 
> computers name and ipaddress and then joined to the domain, if the old 
> computer was then restarted, you would have two computers with the 
> same name, but with different SID's, GUID's etc, not a good thing.
>
> The only way around all that, in your one DC domain, would be to 
> backup the entire machine and then bring that back (after turning off 
> any other new DC's).
>
> Basically, the more DC's you have, the more robust your domain is.
>
Devil's advocating - it takes less than an hour to restore the DC from 
backup (I know, I just did it). What kind of time would be involved in 
correctly fixing up Group Policies in a new DC? Even if ahead of a DC 
crash I could search for and identify all GPOs with explicit host 
references, I'll bet it would take me more than an hour to edit them -- 
if the GPOs were already in the other DCs' database -- something we're 
not sure is true unless someone else weighs in on this. Meanwhile, 
Windows workstations "remember" the user's domain credentials and can 
log in the absence of a DC; and redirected folders have the option set 
to work offline, presumably syncing when the DC is back up. So, users 
could happily continue working while the DC is restoring, being none the 
wiser.

In view of the idea of staging and switching to a 2nd DC being fraught 
with unknown perils, I'm thinking about taking another run at upgrading 
my 4.8.2 DC and maybe trying the 2nd DC idea later. In the course of 
this thread you mentioned that my upgrade should have worked but 
probably had some conflicts with old paths; and you and Michael Tokarev 
have given me lots of insight into things I didn't configure right, e.g. 
kerberos.

But - pursuing that idea will require questions in a whole new email.

Thanks --Mark