Bug 13043 - Workstation DNS updates fail
Summary: Workstation DNS updates fail
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other (show other bugs)
Version: 4.6.7
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-20 02:06 UTC by Daniel A. Veiga
Modified: 2017-09-21 05:59 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel A. Veiga 2017-09-20 02:06:00 UTC
Upon installation of Samba as an AD DC with bind dlz every domain workstation DNS update fails. Theese are the facts I traced:

1) The terminal does a "non-signed" attempt to update first. Its rejected, unauthorized.
2) Then terminal successfully obtains the kerberos ticket for the DNS service.
3) A second "signed" attempt is sent to bind.
4) Bind checks the ticket and notices it's valid and accepts the update.
5) Bind calls it's dlz database function "dlz_ssumatch" to see if the user us authorized to update de zone.
6) The verification process always fails in "dlz_ssumatch()", in source4/dns_server/dlz_bind9.c, with error "samba_dlz: spnego update failed". This is caused by "gensec_update()" returning NT_STATUS_LOGON_FAILURE.

I'll spend some more time digging into the problem, but I don't know yet what "gensec_update()" does and why it is inmersed in comments like 'remove this hack once the backends are fixed'. Just a question of time......
Comment 1 Daniel A. Veiga 2017-09-20 02:51:40 UTC
A step more:

Upon entry to "gensec_update()" gensec_security->ops is of type "spnego", but while inside that function, a second (recursive) call to "gensec_update()" uses gensec_security->ops of type "gssapi_krb5". This takes the problem into samba4/auth/gensec/gensec_gssapi.c.
Comment 2 Daniel A. Veiga 2017-09-21 05:59:17 UTC
I managed to understand the problem. The error appears in source4/auth/gensec/gensec_gssapi.c, line 639, when gss_accept_sec_context() is called. The error is 'Unspecified GSS failure. Minor code may provide more information: Request is a replay'.
The only alternative here is that when Windows accesses the DNS server and creates the context, it specifies GSS_C_REPLAY_FLAG. As bind opens the ticket to validate de signature, when samba dlz shared object uses gss_accept_sec_context to open it again it is considered a "Replay".
Of course we can't change Windows behaviour, so the ticket can be accepted only once. Either we change bind not to open it first, or we allow it to do so and change the dlz database interface to make it share the acquired context to be used by samba.
Both are design decisions, I believe I can't help any more.