Bug 12786 - DNS snap-in cannot access server
DNS snap-in cannot access server
Status: REOPENED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.5.0
All Linux
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-11 17:30 UTC by Kristján Jónsson
Modified: 2017-05-29 17:35 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristján Jónsson 2017-05-11 17:30:55 UTC
I have a setup with Samba AD and a Named backend.
Everything has been working fine, until a few days ago, I cannot start the DNS snap-in from windows.  I get a dialog box saying
"Access was denied. Would you like to add it anyway?"

If I enable level 3 debugging in the samba.conf, I get the following:

[2017/05/11 07:25:30.413481,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ kristjan@RVX.IS from ipv4:192.168.253.109:57310 for DnsServerApp@RVX.IS [canonicalize, renewable, forwardable]
[2017/05/11 07:25:30.414016,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Searching referral for DnsServerApp
[2017/05/11 07:25:30.414141,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Server not found in database: DnsServerApp@RVX.IS: No such entry in the database
[2017/05/11 07:25:30.414215,  3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed building TGS-REP to ipv4:192.168.253.109:57310
[2017/05/11 07:25:30.415231,  3] ../source4/smbd/service_stream.c:66(stream_terminate_connection)


I googled a lot for this, particularly "DnsServerApp" and found no solution.  In desperation, using the ActiveDirectory, I added a "Computer" entry called "DnsServerApp".
This didn't resolve the issue, but changed it.  Now I get in the log:

[2017/05/11 12:23:29.195608,  3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect)
  ldb_wrap open of secrets.ldb
[2017/05/11 12:23:29.199719,  1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find DC01$@RVX.IS(kvno 2) in keytab FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5)
[2017/05/11 12:23:29.199832,  1] ../auth/gensec/spnego.c:545(gensec_spnego_parse_negTokenInit)
  SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2017/05/11 12:23:29.199925,  2] ../auth/gensec/spnego.c:720(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_LOGON_FAILURE

The DC is called dc01.rvx.is.
Curiously, even after I removed the AD "computer" entry DnsServerApp, I still get the above, second, error in the log.

I'm relatively new to both Samba and AD configuration, but having failed to find any reference to the above problems on the net, I think they may be due to some internal database corruption or other such things.  Any thoughts?
Comment 1 Phillip R. Jaenke 2017-05-20 20:17:53 UTC
Confirming this bug was introduced in 4.5.8 and that 4.5.7 does NOT exhibit this problem. Tested with identical results on FreeBSD 11.0-RELEASE-p11 12.0-313109. Issue is clearly internal Samba defect. Priority needs to be highest as this will screw anyone upgrading from 4.5.7. samba_upgradedns does not help; this is clearly a bug. Debug 10 output follows...

Kerberos: TGS-REQ Administrator@ROOTWYRM.PVT from ipv4:10.10.1.132:51407 for DnsServerApp@ROOTWYRM.PVT [canonicalize, renewable, forwardable]
Kerberos: Searching referral for DnsServerApp
Kerberos: Server not found in database: DnsServerApp@ROOTWYRM.PVT: No such entry in the database
Kerberos: Failed building TGS-REP to ipv4:10.10.1.132:51407
Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
ldb_wrap open of secrets.ldb
Starting GENSEC mechanism ntlmssp
Got NTLMSSP neg_flags=0xe208b297
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_NEGOTIATE_OEM
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_LM_KEY
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED
  NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
  NTLMSSP_NEGOTIATE_56
Got user=[Administrator] domain=[ROOTWYRM] workstation=[INETPRAWN] len1=24 len2=302
auth_check_password_send: Checking password for unmapped user [ROOTWYRM]\[Administrator]@[INETPRAWN]
map_user_info_cracknames: Mapping user [ROOTWYRM]\[Administrator] from workstation [INETPRAWN]
auth_check_password_send: mapped user is: [ROOTWYRM]\[Administrator]@[INETPRAWN]
auth_get_challenge: returning previous challenge by module random (normal)
[0000] 4C FA BB 2A 90 D6 79 20                             L..*..y
ntlm_password_check: Checking NTLMv2 password with domain [ROOTWYRM]
authsam_account_ok: Checking SMB password for user Administrator
logon_hours_ok: No hours restrictions for user Administrator
lastLogonTimestamp is 131397738835817440
sync interval is 14
randomised sync interval is 13 (-1)
old timestamp is 131397738835817440, threshold 131386524829249840, diff 11214006567600
auth_check_password_recv: sam_ignoredomain authentication for user [ROOTWYRM\Administrator] succeeded
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0xe2088215
  NTLMSSP_NEGOTIATE_UNICODE
  NTLMSSP_REQUEST_TARGET
  NTLMSSP_NEGOTIATE_SIGN
  NTLMSSP_NEGOTIATE_NTLM
  NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
  NTLMSSP_NEGOTIATE_VERSION
  NTLMSSP_NEGOTIATE_128
  NTLMSSP_NEGOTIATE_KEY_EXCH
  NTLMSSP_NEGOTIATE_56
dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.132:51406]
Comment 2 Garming Sam 2017-05-25 00:19:57 UTC
(In reply to Phillip R. Jaenke from comment #1)

There are no changes beyond the security fixes in a completely unrelated area between 4.5.7 and 4.5.8. The fact that both of your logs indicate a user 'DnsServerApp' that simply does not exist looks like the DNS snap-in has possibly been updated to use a new user. There is no reference to this user anywhere as both have you have noticed, including in Samba code. So where it came from, or where it is supposed to come from is a complete mystery to myself.
Comment 3 Phillip R. Jaenke 2017-05-25 01:07:51 UTC
(In reply to Garming Sam from comment #2)

Yep, that is most definitely the case. Here's where things take a turn for the strange: in the previously working setup (4.5.7, FreeBSD ports), I did not have the DnsServerApp user or group. But access was not denied either - it simply used the DOMAIN\Administrator user (or whatever user I had logged in as) and worked as expected.

I think the DnsServerApp is symptomatic of a fall-through condition that wasn't previously being hit. Since obviously DOMAIN\Administrator (who is a member of the Enterprise Admins group) would have the required permissions. Otherwise nsupdate -g would fail, which it does not.
Unfortunately, I am simply not familiar enough with the source to identify where this fall-through condition could even be located. And as you can see, the debugging details at 10 aren't shining a lot of light on why this is happening.
Comment 4 Garming Sam 2017-05-25 02:03:21 UTC
(In reply to Phillip R. Jaenke from comment #3)

Can you tell me what specific version of Windows you're running (and a build number if you can)?
Comment 5 Phillip R. Jaenke 2017-05-25 02:18:30 UTC
(In reply to Garming Sam from comment #4)

Now comes the fun... tested and verified identical behavior with:
Windows 10 1703 build 15063.296 with RSAT - both joined to domain AND un-joined using 'runas'
Windows 2008R2 Enterprise 7601.23796
Windows 2012R2 Standard 9600.18685
Windows 2003 (not sure which build as I deleted that VM)

So basically everything but 7/8/2016 had the same issue.
Comment 6 Kristján Jónsson 2017-05-26 12:18:41 UTC
This problem went away when I rebooted the client.
Comment 7 Phillip R. Jaenke 2017-05-28 20:59:47 UTC
Still reproducing on Samba 4.5.10. No sign of "DnsServerApp" this time.

ldb: Destroying timer event 0x422d8c60 "ltdb_timeout"

ldb: Ending timer event 0x422da8e0 "ltdb_callback"

gendb_search_v: NULL objectSid=\01\02\00\00\00\00\00\05\20\00\00\00\20\02\00\00 -> 1
ldb: ldb_trace_request: SEARCH
 dn: <rootDSE>
 scope: sub
 expr: (objectSid=\01\02\00\00\00\00\00\05\20\00\00\00\21\02\00\00)
 attr: privilege
 control: <NONE>

ldb: ldb_trace_request: (tdb)->search
ldb: Added timed event "ltdb_callback": 0x422da5e0

ldb: Added timed event "ltdb_timeout": 0x422d8c60

ldb: Running timer event 0x422da5e0 "ltdb_callback"

ldb: Destroying timer event 0x422d8c60 "ltdb_timeout"

ldb: Ending timer event 0x422da5e0 "ltdb_callback"

gendb_search_v: NULL objectSid=\01\02\00\00\00\00\00\05\20\00\00\00\21\02\00\00 -> 0
ldb: ldb_trace_request: SEARCH
 dn: <rootDSE>
 scope: sub
 expr: (objectSid=\01\02\00\00\00\00\00\05\20\00\00\00\2A\02\00\00)
 attr: privilege
 control: <NONE>

ldb: ldb_trace_request: (tdb)->search
ldb: Added timed event "ltdb_callback": 0x422da8e0

ldb: Added timed event "ltdb_timeout": 0x422d8c60

ldb: Running timer event 0x422da8e0 "ltdb_callback"

ldb: ldb_trace_response: ENTRY
dn: sid=S-1-5-32-554
privilege: SeRemoteInteractiveLogonRight
privilege: SeChangeNotifyPrivilege



ldb: Destroying timer event 0x422d8c60 "ltdb_timeout"

ldb: Ending timer event 0x422da8e0 "ltdb_callback"

gendb_search_v: NULL objectSid=\01\02\00\00\00\00\00\05\20\00\00\00\2A\02\00\00 -> 1
Security token SIDs (13):
  SID[  0]: S-1-5-21-2188739288-3022048767-3733453647-500
  SID[  1]: S-1-5-21-2188739288-3022048767-3733453647-513
  SID[  2]: S-1-5-21-2188739288-3022048767-3733453647-520
  SID[  3]: S-1-5-21-2188739288-3022048767-3733453647-572
  SID[  4]: S-1-5-21-2188739288-3022048767-3733453647-519
  SID[  5]: S-1-5-21-2188739288-3022048767-3733453647-518
  SID[  6]: S-1-5-21-2188739288-3022048767-3733453647-512
  SID[  7]: S-1-1-0
  SID[  8]: S-1-5-2
  SID[  9]: S-1-5-11
  SID[ 10]: S-1-5-32-544
  SID[ 11]: S-1-5-32-545
  SID[ 12]: S-1-5-32-554
 Privileges (0x        1FFFFF00):
  Privilege[  0]: SeTakeOwnershipPrivilege
  Privilege[  1]: SeBackupPrivilege
  Privilege[  2]: SeRestorePrivilege
  Privilege[  3]: SeRemoteShutdownPrivilege
  Privilege[  4]: SeSecurityPrivilege
  Privilege[  5]: SeSystemtimePrivilege
  Privilege[  6]: SeShutdownPrivilege
  Privilege[  7]: SeDebugPrivilege
  Privilege[  8]: SeSystemEnvironmentPrivilege
  Privilege[  9]: SeSystemProfilePrivilege
  Privilege[ 10]: SeProfileSingleProcessPrivilege
  Privilege[ 11]: SeIncreaseBasePriorityPrivilege
  Privilege[ 12]: SeLoadDriverPrivilege
  Privilege[ 13]: SeCreatePagefilePrivilege
  Privilege[ 14]: SeIncreaseQuotaPrivilege
  Privilege[ 15]: SeChangeNotifyPrivilege
  Privilege[ 16]: SeUndockPrivilege
  Privilege[ 17]: SeManageVolumePrivilege
  Privilege[ 18]: SeImpersonatePrivilege
  Privilege[ 19]: SeCreateGlobalPrivilege
  Privilege[ 20]: SeEnableDelegationPrivilege
 Rights (0x             403):
  Right[  0]: SeInteractiveLogonRight
  Right[  1]: SeNetworkLogonRight
  Right[  2]: SeRemoteInteractiveLogonRight
../librpc/rpc/dcerpc_util.c:233: auth_pad_length 4
dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:57071]
Terminating connection - 'dcesrv: NT_STATUS_CONNECTION_DISCONNECTED'
single_terminate: reason[dcesrv: NT_STATUS_CONNECTION_DISCONNECTED]
msg_dgm_ref_destructor: refs=0x422c3c20
ldb: ldb_trace_request: SEARCH
 dn: DC=ForestDnsZones,DC=rootwyrm,DC=pvt
 scope: base
 expr: (|(objectClass=*)(distinguishedName=*))
 attr: repsTo
 control: <NONE>
Comment 8 Kristján Jónsson 2017-05-29 10:26:55 UTC
 Hello there!
I'm sorry but my email filter had hidden all the email from the bug tracker and I didn't realize this was getting attention.

Anyway:
I´m running windows 10 Enterprise.
And while I went away and worried about other things for a while, my computer received security updates from MS and rebooted.  Since then, I haven't seen this issue.  I changed nothing on the DC.

I changed the issue state to "worksforme" but there definitely is a problem somewhere.
Comment 9 Kristján Jónsson 2017-05-29 10:29:42 UTC
Reopening, since I closed it in error.
Comment 10 Phillip R. Jaenke 2017-05-29 17:35:37 UTC
(In reply to Kristján Jónsson from comment #9)
No worries, Kristján! It looks like there are actually two bugs going on here; I opened a separate bug at #12807 which may be directly related but is slightly different.