dsdb_trust_routing_table_load() fails when dsdb_trust_xref_forest_info() try to search objectClass=crossRef if trusted domain exists: ret = dsdb_search(sam_ctx, partitions_dn, &cross_res2, partitions_dn, LDB_SCOPE_ONELEVEL, cross_attrs2, DSDB_SEARCH_SHOW_EXTENDED_DN, "(&(objectClass=crossRef)" "(systemFlags:%s:=%u))", LDB_OID_COMPARATOR_AND, SYSTEM_FLAG_CR_NTDS_DOMAIN); This problem reproduced manually: #### On Samba DC #### [user@samba-dc ~]$ ldbsearch -k yes -H ldap://samba-dc -b CN=Partitions,CN=Configuration,DC=adm72,DC=local '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' dnsRoot nETBIOSName nCName rootTrust trustParent -d0 # record 1 dn: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=adm72,DC=local dnsRoot: adm72.local nETBIOSName: ADM72 # record 2 dn: CN=OMSU,CN=Partitions,CN=Configuration,DC=adm72,DC=local dnsRoot: omsu.adm72.local nETBIOSName: OMSU trustParent: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local # returned 2 records # 2 entries # 0 referrals #### On Windows DC #### [user@samba-dc ~]$ ldbsearch -k yes -H ldap://dc-resp142 -b CN=Partitions,CN=Configuration,DC=adm72,DC=local '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' dnsRoot nETBIOSName nCName rootTrust trustParent -d0 # record 1 dn: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=adm72,DC=local dnsRoot: adm72.local nETBIOSName: ADM72 # record 2 dn: CN=OMSU,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=omsu,DC=adm72,DC=local dnsRoot: omsu.adm72.local nETBIOSName: OMSU trustParent: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local # returned 2 records # 2 entries # 0 referrals For user it looks like problem with not works KDC when building TGS request: [root at samba-dc ~]# smbclient -k -L //samba-dc.adm72.local SPNEGO(gse_krb5) creating NEG_TOKEN_INIT for cifs/samba-dc.adm72.local failed (next[(null)]): NT_STATUS_NO_LOGON_SERVERS SPNEGO: Could not find a suitable mechtype in NEG_TOKEN_INIT session setup failed: NT_STATUS_NO_LOGON_SERVERS log.samba: [2017/10/03 17:52:06.314034, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: TGS-REQ basealt at ADM72.LOCAL from ipv4:10.142.170.14:52384 for cifs/alt-srv-dc-02 at ADM72.LOCAL [canonicalize] [2017/10/03 17:52:06.316473, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: target does not have secrets at this KDC, need to proxy [2017/10/03 17:52:06.316570, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Failed building TGS-REP to ipv4:10.142.170.14:52384 [2017/10/03 17:52:06.316651, 3] ../source4/smbd/service_stream.c:66(stream_terminate_connection) Terminating connection - 'kdc_tcp_call_loop: proxying requested when not RODC' [2017/10/03 17:52:06.316719, 3] ../source4/smbd/process_single.c:114(single_terminate) single_terminate: reason[kdc_tcp_call_loop: proxying requested when not RODC] More details described in thread: https://lists.samba.org/archive/samba-technical/2017-October/123244.html So, main problem is in LDAP response from Samba, that don't revert nCName attribute for trusted domain: [user@samba-dc ~]$ ldbsearch -k yes -H ldap://samba-dc -b CN=Partitions,CN=Configuration,DC=adm72,DC=local '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' nCName systemFlags -d0 # record 1 dn: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=adm72,DC=local systemFlags: 3 # record 2 dn: CN=OMSU,CN=Partitions,CN=Configuration,DC=adm72,DC=local systemFlags: 3 # returned 2 records # 2 entries # 0 referrals But in database this attribute with right systemFlags exists: [root@samba-dc ~]# ldbsearch -H /var/lib/samba/private/sam.ldb.d/CN\=CONFIGURATION\,DC\=ADM72\,DC\=LOCAL.ldb -b CN=Partitions,CN=Configuration,DC=adm72,DC=local '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' nCName systemFlags -d0 # record 1 dn: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: <GUID=20f2eac9-426d-4003-b9c8-0f2737f982f9>;<SID=S-1-5-21-3196609985-6 36931310-2637777318>;DC=adm72,DC=local systemFlags: 3 # record 2 dn: CN=OMSU,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: <GUID=2db28977-e989-4528-bb73-af31dfaad9a7>;<SID=S-1-5-21-925305307-17 29258221-3996020766>;DC=omsu,DC=adm72,DC=local systemFlags: 3 # returned 2 records # 2 entries # 0 referrals
(In reply to Evgeny Sinelnikov from comment #0) Please note that there're no real support for forests with more than one domain, there will be a lot of things which are broken, sorry.
I found the reason of problem: https://lists.samba.org/archive/samba-technical/2017-October/123302.html 'nCName' attribute removed as one way link. And it is a bug... I found solution (apply patch next message) - don't delete explicit list of attributes [root@samba-dc RPMS.hasher]# ldbsearch -H /var/lib/samba/private/sam.ldb -b CN=Partitions,CN=Configuration,DC=adm72,DC=local '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' systemFlags objectGUID nCName --cross-ncs -d0 # record 1 dn: CN=ADM72,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=adm72,DC=local objectGUID: 251e4849-921f-4d28-ad6a-da8aa4348925 systemFlags: 3 # record 2 dn: CN=OMSU,CN=Partitions,CN=Configuration,DC=adm72,DC=local nCName: DC=omsu,DC=adm72,DC=local objectGUID: 1258a934-cb2d-467d-b4a9-5105756cba94 systemFlags: 3 # returned 2 records # 2 entries # 0 referrals
Created attachment 13680 [details] one-way links for explicitly requested attributes Don't fixup explicitly requested attributes in extended_callback().
Comment on attachment 13680 [details] one-way links for explicitly requested attributes Thanks for the patch. The issue is that without psudo-backlinks we can't know if the target of the link has been renamed or deleted (until a full scan in dbcheck). Across partitions it is even more tricky. Therefore we still need to fix this up, even if they are asked for explicitly.
(In reply to Andrew Bartlett from comment #4) So, we have two questions: 1) Where we will need "need to fix this up, even if they are asked for explicitly"? Why it not works same as on Windows DC for 'nCName' attribute on objectClass=crossRef? 2) How we will fix KDC TGS problem with realm lookup fail during dsdb_trust_routing_table_load(), where dsdb_trust_xref_forest_info() try to search for '(&(objectClass=crossRef)(systemFlags:1.2.840.113556.1.4.803:=2))' and wait for nCName would not be absent (even it is one way link) if request complete successfully? https://lists.samba.org/archive/samba-technical/2017-October/123244.html
Created attachment 13688 [details] Avoid TGS request problem with crossRef class. Logging and avoid TGS request problem with forest trust information for crossRef class object nCName attribute.
(In reply to Evgeny Sinelnikov from comment #5) Windows does not store linked attributes in the same way that we do, so does not suffer the same consistency issues. We need to solve the problem of links outside our known NCs generically.
(In reply to Andrew Bartlett from comment #7) Ok, but it's so not obvious, when explicitly requested attribute could not be return if request was successful, that this potential consistency issues could be resolved on client part. It would be set by no default additional request control flag like DSDB_CLEANUP_ONE_WAY_LINKS.