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
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.> > 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. Rowland
30.01.2023 06:14, Mark Foley via samba ?????: [,,]> 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?Do not store regular files on a DC. The file server functions of samba DC are different and works differently from a regular samba fileserver (be it a member of a domain or not). You have to have *another* server to store user files, and point your Root Path to that. /mjt