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?
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]
(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.
(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.
(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)?
(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.
This problem went away when I rebooted the client.
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>
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.
Reopening, since I closed it in error.
(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.
as reported, client reboot fixed its mmc issued