[Samba] Replication fails after DC re-joined to domain

[Roy Eastwood]

Hi Rowland,

> -----Original Message-----
> From: samba [mailto:samba-bounces at lists.samba.org] On Behalf Of Rowland
> Penny via samba
> Sent: 07 February 2018 16:52
> To: samba at lists.samba.org
> Subject: Re: [Samba] Replication fails after DC re-joined to domain
> 
> On Wed, 7 Feb 2018 16:30:56 -0000
> Roy Eastwood via samba <samba at lists.samba.org> wrote:
> 
> > Hi,
> > First some background:
> > ==================
> > I had a test environment which had two samba DCs (running v 4.8.0rc2)
> > and 1 Windows Server 2008R2 DC.    The samba DCs had been upgraded
> > from v 4.6x and the secrets database was not encrypted (as far as I
> > know).    I decided to downgrade one of the samba DCs to v 4.7.4.
> >
> > On re-starting samba after the downgrade the log shows:
> >
> > ldb: unable to dlopen /usr/local/samba/lib/ldb/encrypted_secrets.so :
> > /usr/local/samba/lib/private/libdsdb-module-samba4.so: version
> > `SAMBA_4.8.0RC2' not found (required
> > by /usr/local/samba/lib/ldb/encrypted_secrets.so)
> >
> > and the samba daemons are left in a failed state.
> >
> > So I removed this failed DC (dc1) from the domain, using the
> > (working) 4.8.0rc2 samba machine after seizing the FSMO roles and
> > using the remove-other-dead-server option.   I removed all traces of
> > the existing samba installation and then installed a freshly compiled
> > copy of v. 4.7.5 and re-joined the domain.   All was working,
> > including replication (as far as I know).
> >
> > I then demoted the other 4.8.0rc2 samba machine (dc2), with the same
> > result, so had to repeat the seizing of roles and removal then
> > install 4.7.5 and re-join.
> >
> 
> Strange, if you read the release notes for 4.8.0rc2. you will
> find this:
> 
> Encrypted secrets
> 
> Attributes deemed to be sensitive are now encrypted on disk. The sensitive
> values are currently: pekList msDS-ExecuteScriptPassword currentValue
> dBCSPwd initialAuthIncoming initialAuthOutgoing lmPwdHistory ntPwdHistory
> priorValue supplementalCredentials trustAuthIncoming trustAuthOutgoing
> unicodePwd clearTextPassword
> 
> This encryption is enabled by default on a new provision or join, it can be disabled
> at provision or join time with the new option '--plaintext-secrets'.
> 
> However, an in-place upgrade will not encrypt the database.
> 
> Once encrypted, it is not possible to do an in-place downgrade (eg to 4.7) of the
> database. To obtain an unencrypted copy of the database a new DC join should
> be performed, specifying the '--plaintext-secrets' option.
> 
> The key file "encrypted_secrets.key" is created in the same directory
> as the database and should NEVER be disclosed. It is included by the
> samba_backup script.
> 
> The operative phrase is:
> 
> However, an in-place upgrade will not encrypt the database.
> 
> So, by my reading, you should be able to upgrade without the secrets
> being encrypted, but it seems they were, or Samba seems to think they
> were.
> 
> Whichever is true, this is (in my opinion) a bug, I suggest you raise a
> bugreport.
> 
> Rowland
> 

Thanks for your prompt reply.  Yes, that's what I thought.  I'll file a bug report as you suggest. 
Roy