Bug 34910

Summary:	DDNS update with wrong ownersid
Product:	UCS	Reporter:	Stefan Gohmann <gohmann>
Component:	S4 Connector	Assignee:	Lukas Oyen <oyen>
Status:	CLOSED DUPLICATE	QA Contact:	Arvid Requate <requate>
Severity:	normal
Priority:	P5	CC:	michelsmidt, requate
Version:	UCS 4.2
Target Milestone:	UCS 4.2-1-errata
Hardware:	Other
OS:	Linux
See Also:	https://forge.univention.org/bugzilla/show_bug.cgi?id=33637
What kind of report is it?:	Bug Report	What type of bug is this?:	3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?:	1: Will affect a very few installed domains	How will those affected feel about the bug?:	2: A Pain – users won’t like this once they notice it
User Pain:	0.034	Enterprise Customer affected?:	Yes
School Customer affected?:		ISV affected?:
Waiting Support:		Flags outvoted (downgraded) after PO Review:
Ticket number:	2014051921010488	Bug group (optional):
Max CVSS v3 score:
Bug Depends on:	39806
Bug Blocks:

Description Stefan Gohmann

2014-05-22 07:17:12 CEST

Ticket #2014051921010488 (2 S4 DCs and one Windows 8.1 client)

It happens from time to time that the DNS record of a new joined windows client has as owner not the windows client:

nTSecurityDescriptor: O:DAG:DAD:AI(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWP

Thus the windows client is unable to update the DNS record.

Comment 1 Stefan Gohmann

2014-07-06 17:05:15 CEST

It doesn't happen so often.

Comment 2 Arvid Requate

2016-11-04 16:12:07 CET

I guess the S4-Connector might have made the last modification. The DNS mapping is not perfect and doesn't detect that some changes are not required.

Comment 3 Lukas Oyen

2017-05-03 15:35:00 CEST

I am unable to reproduce the problem with a modification throught the S4-Connector, but a manually created DNS forward-zone with `ldbadd` before joining the Windows client reproduces the ownership mismatch.

https://forge.univention.org/bugzilla/attachment.cgi?id=8773 from bug #39806 implements escalation to system-privileges within the bind9 dlz module, if the requesting host matches the forward-zone. This fixes the issue I can reproduce.

Marking as dependent on bug #39806.

Comment 4 Arvid Requate

2017-06-22 11:41:46 CEST

IMHO that's fixed with Bug 39806.

Comment 5 Lukas Oyen

2017-06-22 14:26:24 CEST


*** This bug has been marked as a duplicate of bug 39806 ***

Comment 6 Stefan Gohmann

2018-03-15 08:24:43 CET

Nothing to release.