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