Bug 45126 – Assure that /etc/machine.secret works against Samba on Re-joined S4-Connector DC

Bug 45126 - Assure that /etc/machine.secret works against Samba on Re-joined S4-Connector DC


Summary:	Assure that /etc/machine.secret works against Samba on Re-joined S4-Connector DC

Status:	CLOSED FIXED

Product:	UCS
Classification:	Unclassified
Component:	Samba4
Version:	UCS 4.1
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	UCS 4.1-4-errata
Assigned To:	Arvid Requate
QA Contact:	Felix Botner

URL:
Keywords:

Depends on:	45111
Blocks:
	Show dependency tree / graph

Reported:	2017-08-02 19:16 CEST by Arvid Requate
Modified:	2017-08-16 13:34 CEST (History)
CC List:	0 users

See Also:
What kind of report is it?:	Bug Report
What type of bug is this?:	7: Crash: Bug causes crash or data loss
Who will be affected by this bug?:	1: Will affect a very few installed domains
How will those affected feel about the bug?:	5: Blocking further progress on the daily work
User Pain:	0.200
Enterprise Customer affected?:	Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:	2017073121000288
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Arvid Requate

2017-08-02 19:16:22 CEST

After fixing Bug #45111 re-joins of a S4-Connector DC lead to a situation, where

1. secrets.ldb and krb5.keytab work against the sam.ldb hashes
2. machine.secret matches OpenLDAP hashes

But 1 and 2 don't match because the join changed the machine.secret.

So the setup-s4.sh script which is used for the (re-)provision of S4-Connector DCs needs to check the credentials and assert that the machine.secret works against sam.ldb



+++ This bug was initially created as a clone of Bug #45111 +++

Now, when I have the S4-Connector on a DC Backup (only) I can uninstall univention-samba4 and reinstall univention-s4-connector and everything continues to work, so we got Bug 44787 covered.


But to cover the situation of Ticket #2017073121000288 we need to do one additional thing: It should also work for re-joins, but in that case samba needs to be informed about the new machine.secret. I guess we should split that into a separate Bug, to be able to fix that transparently in errata4.2-1 and errata4.1-4

Comment 1 Arvid Requate

2017-08-02 20:31:52 CEST

I've added some check functions to verify that

1. secrets.ldb works against the sam.ldb hashes
2. krb5.keytab works against the sam.ldb hashes
3. machine.secret works against the sam.ldb hashes

If 1 fails, the Samba AD/DC needs to be re-provisioned.

As an additional safety belt before finally allowing re-provision I have added a check if connector/s4/mapping/sid_to_ucs is true. If that is the case, and the sam.ldb contains at least the machine account, then the setup-s4.sh script exits with a failure.

I've also added more log output about what is happening.

r81732 Keep old KVNOs if possible when recreating krb5.keytab is necessary
r81733 Assure that /etc/machine.secret works against Samba on re-joined 
       S4-Connector DC.
r81735 Additionally abort re-provision if sam.ldb is not functional but
       connector/s4/mapping/sid_to_ucs is true.


Advisory: univention-samba4.yaml

Comment 2 Felix Botner

2017-08-16 11:47:50 CEST

not quite sure what to test here, i have done the following:

OK - master (s4 + con), backup (s4), slave (s4)
 master run s4 join script  -> no re-provisioning
 backup rejoin -> domain join
 slave rejoin -> domain join


OK - master (s4), backup (s4 + con), slave (s4)
 backup rejoin -> no re-provisioning
 slave rejoin -> domain join 
 master run s4 join script -> domain join

OK - school DC rejoin -> "school" domain join

OK - YAML

Comment 3 Erik Damrose

2017-08-16 13:34:13 CEST

<http://errata.software-univention.de/ucs/4.1/448.html>