Bug 13078 - dsdb_search() don't return nCName attribute for trusted domain
dsdb_search() don't return nCName attribute for trusted domain
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.6.8
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-09 22:44 UTC by Evgeny Sinelnikov
Modified: 2017-10-14 22:00 UTC (History)
4 users (show)

See Also:


Attachments
one-way links for explicitly requested attributes (1.41 KB, patch)
2017-10-12 07:50 UTC, Evgeny Sinelnikov
abartlet: review-
Details
Avoid TGS request problem with crossRef class. (4.21 KB, patch)
2017-10-14 19:36 UTC, Evgeny Sinelnikov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Evgeny Sinelnikov 2017-10-09 22:44:19 UTC
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
Comment 1 Stefan Metzmacher 2017-10-10 14:00:22 UTC
(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.
Comment 2 Evgeny Sinelnikov 2017-10-12 07:43:47 UTC
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
Comment 3 Evgeny Sinelnikov 2017-10-12 07:50:57 UTC
Created attachment 13680 [details]
one-way links for explicitly requested attributes

Don't fixup explicitly requested attributes in extended_callback().
Comment 4 Andrew Bartlett 2017-10-14 08:24:13 UTC
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.
Comment 5 Evgeny Sinelnikov 2017-10-14 19:16:56 UTC
(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
Comment 6 Evgeny Sinelnikov 2017-10-14 19:36:29 UTC
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.
Comment 7 Andrew Bartlett 2017-10-14 20:13:33 UTC
(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.
Comment 8 Evgeny Sinelnikov 2017-10-14 22:00:09 UTC
(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.