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.
Current problem:
=============Replication reports successful when running samba-tool drs showrepl
on both
machines. However, running:
samba-tool drs replicate dc1 dc2 dc=samdom,dc=example,dc=com --full-sync
or
samba-tool drs replicate dc2 dc1 dc=samdom,dc=example,dc=com --full-sync
on dc1 it runs fine. Indeed dc1 can do a full replication to the Windows DC as
well.
But running the command
samba-tool drs replicate dc1 dc2 dc=samdom,dc=example,dc=com --full-sync
on dc2 produces an error:
ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to
dc1 failed -
drsException: DRS connection to dc1 failed: (-1073741643, '{Device Timeout}
The
specified I/O operation on %hs was not completed before the time-out period
expired.')
File
"/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/drs.py",
line
44, in drsuapi_connect
(ctx.drsuapi, ctx.drsuapi_handle, ctx.bind_supported_extensions)
drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds)
File
"/usr/local/samba/lib/python2.7/site-packages/samba/drs_utils.py",
line
56, in drsuapi_connect
raise drsException("DRS connection to %s failed: %s" % (server,
e))
and the logs show:
[2018/02/07 16:02:50.440699, 1]
../source4/auth/gensec/gensec_gssapi.c:790(gensec_gssapi_update_internal)
GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text):
Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type
aes256-cts-hmac-sha1-96
[2018/02/07 16:02:50.440729, 1]
../auth/gensec/spnego.c:411(gensec_spnego_parse_negTokenInit)
SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
Replication is OK in the other direction on dc2: ie
samba-tool drs replicate dc2 dc1 dc=samdom,dc=example,dc=com --full-sync
works ok.
samba-tool dbcheck --cross-ncs shows no errors when run on either machine.
Any help appreciated,
TIA
Roy
Rowland Penny
2018-Feb-07 16:51 UTC
[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
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
Hi Roy,> 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)when you are doing your downgrade, did you clean up all the /usr/local/samba directory or did you make && make install over the existing installation? If it was a quick'n dirty make && make install over the existing 4.8 install, could you try to do a install on a clean directory and then copy over etc/smb.conf, private/ and var/locks/? Cheers, Denis> > 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. > > Current problem: > =============> Replication reports successful when running samba-tool drs showrepl on both > machines. However, running: > > samba-tool drs replicate dc1 dc2 dc=samdom,dc=example,dc=com --full-sync > or > samba-tool drs replicate dc2 dc1 dc=samdom,dc=example,dc=com --full-sync > > on dc1 it runs fine. Indeed dc1 can do a full replication to the Windows DC as > well. > > But running the command > samba-tool drs replicate dc1 dc2 dc=samdom,dc=example,dc=com --full-sync > on dc2 produces an error: > > ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to dc1 failed - > drsException: DRS connection to dc1 failed: (-1073741643, '{Device Timeout} The > specified I/O operation on %hs was not completed before the time-out period > expired.') > File "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/drs.py", line > 44, in drsuapi_connect > (ctx.drsuapi, ctx.drsuapi_handle, ctx.bind_supported_extensions) > drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds) > File "/usr/local/samba/lib/python2.7/site-packages/samba/drs_utils.py", line > 56, in drsuapi_connect > raise drsException("DRS connection to %s failed: %s" % (server, e)) > > and the logs show: > [2018/02/07 16:02:50.440699, 1] > ../source4/auth/gensec/gensec_gssapi.c:790(gensec_gssapi_update_internal) > GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): > Decrypt integrity check failed for checksum type hmac-sha1-96-aes256, key type > aes256-cts-hmac-sha1-96 > [2018/02/07 16:02:50.440729, 1] > ../auth/gensec/spnego.c:411(gensec_spnego_parse_negTokenInit) > SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE > > Replication is OK in the other direction on dc2: ie > samba-tool drs replicate dc2 dc1 dc=samdom,dc=example,dc=com --full-sync > > works ok. > > samba-tool dbcheck --cross-ncs shows no errors when run on either machine. > > Any help appreciated, > TIA > Roy > >-- Denis Cardon Tranquil IT Systems Les Espaces Jules Verne, bâtiment A 12 avenue Jules Verne 44230 Saint Sébastien sur Loire tel : +33 (0) 2.40.97.57.55 http://www.tranquil-it-systems.fr
Andrew Bartlett
2018-Feb-07 17:45 UTC
[Samba] Replication fails after DC re-joined to domain
On Wed, 2018-02-07 at 18:38 +0100, Denis Cardon via samba wrote:> Hi Roy, > > > 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) > > when you are doing your downgrade, did you clean up all the > /usr/local/samba directory or did you make && make install over the > existing installation? > > If it was a quick'n dirty make && make install over the existing 4.8 > install, could you try to do a install on a clean directory and then > copy over etc/smb.conf, private/ and var/locks/? > > Cheers, > > DenisThis is exactly the issue. The install has left an ldb plugin (encrypted_secrets.so) around which blocks operation as it can't operate with the older Samba version but isn't overwritten as it didn't exist in the older version. However I also need to write up about the GUID index change, which also prevents in-place downgrades. It seems I forgot to mention that in the WHATSNEW. (That requires running source4/scripting/bin/sambaundoguididx before any downgrade in-place from 4.8 to 4.7 and below). Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Hi Denis,> -----Original Message----- > From: Denis Cardon [mailto:dcardon at tranquil.it] > Sent: 07 February 2018 17:38 > To: Roy Eastwood; samba at lists.samba.org > Subject: Re: [Samba] Replication fails after DC re-joined to domain > > Hi Roy, > > > 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) > > when you are doing your downgrade, did you clean up all the > /usr/local/samba directory or did you make && make install over the > existing installation? > > If it was a quick'n dirty make && make install over the existing 4.8 > install, could you try to do a install on a clean directory and then > copy over etc/smb.conf, private/ and var/locks/? > > Cheers, > > Denis >It was the quick and dirty make and make install ;-) Yes, I thought about that, thinking the new version had left some files around, but decided to leave and re-join in case the database had got encrypted somehow. Thanks, Roy