samba - Jun 2018 - Domain trust and browsing users and groups problem

Hi list,

we have a forest trust of two domains. One domain in US (us.root.prv)
running exclusively on Windows 2012 R2 and one in EU
(spreadshirt.private) running exclusively Sernet Samba 4.8.2-11. Both
domains run functional level "2008 R2". The trust validates successful
using "samba-tool domain trust validate" and in "Domains and
trusts".

My problem is: I can't browse users and groups of the EU domain on a
domain member of the US domain, when I try to give EU users permissions
on resources in the US domain. The other way does work.

For example:
At a server in the US domain (actually the DC with all FSMO roles of the
US domain), I right-click a folder on disk -> Properties -> Security ->
"Add..." -> "Locations..." -> select forest
"spreadshirt.private" -> OK
-> "Advanced..." -> "Find now".

Search results below show "Searching..." for a short time and then the
message: "The following error prevented the display of any items: The
system cannot contact a domain controller to service the authentication
request. Please try again later."

Doing the same in the EU domain to find users and groups in the US
domain, lists all users and groups as expected.

To track down, what happens, I do a tcpdump at one of the DCs in EU
(ad07), which get the requests from the US server. This is, what I find
(as I think the relevant part):

The krb5 req packet:
US -> EU - KRB5 TGS-REQ
Kerberos
 tgs-req
  pvno: 5
  msg-type: krb-tgs-req (12)
  req-body
   kdc-options: 40810000 (forwardable, renewable, canonicalize)
   realm: SPREADSHIRT.PRIVATE
   sname
    name-type: kRB5-NT-SRV-INST (2)
    sname-string: 3 items
     SNameString: ldap
     SNameString: ad07.spreadshirt.private
     SNameString: spreadshirt.private
   etype: 5 items
    ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
    ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
    ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
    ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5-56 (24)
    ENCTYPE: eTYPE-ARCFOUR-HMAC-OLD-EXP (-135)
   enc-authorization-data
    etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
    cipher: f1cab9899b2402be5267e58829e2573f875f03e4fc1fc04b...

The answer:
EU -> US - KRB5 KRB Error: KRB5KRB_ERR_GENERIC
Kerberos
 krb-error
  pvno: 5
  msg-type: krb-error (30)
  ctime: 2018-06-22 07:49:57 (UTC)
  cusec: 4986
  stime: 2018-06-22 07:49:57 (UTC)
  susec: 828326
  error-code: eRR-GENERIC (60)
  realm: <unspecified realm>
  sname
   name-type: kRB5-NT-UNKNOWN (0)
   sname-string: 0 items
  e-text: No next enctype 18 for hdb-entry

This "No next enctype 18 for hdb-entry" seems to be the problem. AFAIK
is enctype 18 the encryption type AES256-CTS-HMAC-SHA1-96 as seen in the
request packet. After this packet, the connection is ended by the US server.

What does this error mean and how do I solve this?
Without this, we can't add permissions to EU users in US domain.

---

Additional info:
ad07 is the DC with all FSMO roles in EU. It was used to establish the
trust to the US domain by "samba-tool domain trust create" command.
Exactly:
# kinit -c ./cache administrator at US.ROOT.PRV
# samba-tool domain trust create US.ROOT.PRV --type=forest
--direction=both -k yes --krb5-ccache=./cache --create-location=both

smb.conf of ad07:
# Global parameters
[global]
        netbios name = AD07
        realm = SPREADSHIRT.PRIVATE
        server role = active directory domain controller
        workgroup = SPREADSHIRT
        log level = 2 auth_audit:2 auth_json_audit:2
        idmap_ldb:use rfc2307 = yes
        ntlm auth = yes
        ldap server require strong auth = allow_sasl_over_tls

[netlogon]
        path = /var/lib/samba/sysvol/spreadshirt.private/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

"ntlm auth = yes" and "ldap server require strong auth
allow_sasl_over_tls" are needed for freeradius and third-party software.
Removing them and restarting samba services didn't help.

secrets.keytab entries at ad07:
# ktutil -k /var/lib/samba/private/secrets.keytab list
/var/lib/samba/private/secrets.keytab:

Vno  Type                     Principal

  2  des-cbc-crc              HOST/ad07 at SPREADSHIRT.PRIVATE

  2  des-cbc-crc
HOST/ad07.spreadshirt.private at SPREADSHIRT.PRIVATE
  2  des-cbc-crc              AD07$@SPREADSHIRT.PRIVATE

  2  des-cbc-md5              HOST/ad07 at SPREADSHIRT.PRIVATE

  2  des-cbc-md5
HOST/ad07.spreadshirt.private at SPREADSHIRT.PRIVATE
  2  des-cbc-md5              AD07$@SPREADSHIRT.PRIVATE

  2  arcfour-hmac-md5         HOST/ad07 at SPREADSHIRT.PRIVATE

  2  arcfour-hmac-md5
HOST/ad07.spreadshirt.private at SPREADSHIRT.PRIVATE
  2  arcfour-hmac-md5         AD07$@SPREADSHIRT.PRIVATE

  2  aes128-cts-hmac-sha1-96  HOST/ad07 at SPREADSHIRT.PRIVATE

  2  aes128-cts-hmac-sha1-96
HOST/ad07.spreadshirt.private at SPREADSHIRT.PRIVATE
  2  aes128-cts-hmac-sha1-96  AD07$@SPREADSHIRT.PRIVATE

  2  aes256-cts-hmac-sha1-96  HOST/ad07 at SPREADSHIRT.PRIVATE

  2  aes256-cts-hmac-sha1-96
HOST/ad07.spreadshirt.private at SPREADSHIRT.PRIVATE
  2  aes256-cts-hmac-sha1-96  AD07$@SPREADSHIRT.PRIVATE


Ticket cache at US server (rosen):
C:\Windows\system32>klist

Current LogonId is 0:0x607f290

Cached Tickets: (2)

#0>     Client: atmueller @ US.ROOT.PRV
        Server: krbtgt/SPREADSHIRT.PRIVATE @ US.ROOT.PRV
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent
ok_as_delegate name_canonicalize
        Start Time: 6/22/2018 3:46:44 (local)
        End Time:   6/22/2018 13:35:57 (local)
        Renew Time: 6/29/2018 3:35:57 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: ROSEN

#1>     Client: atmueller @ US.ROOT.PRV
        Server: krbtgt/US.ROOT.PRV @ US.ROOT.PRV
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial
pre_authent name_canonicalize
        Start Time: 6/22/2018 3:35:57 (local)
        End Time:   6/22/2018 13:35:57 (local)
        Renew Time: 6/29/2018 3:35:57 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: ROSEN

The whole communication is done for this connection between rosen and
ad07. Full tcpdump trace is available.
In short (US server requests, answered by EU server):
- DNS requests for GC
- CLDAP search for DC capabilities
- LDAP search base <ROOT> at GC port 3268
- Kerberos request as above
- unbind from GC

Any help is appreciated. Thank you.

Tino

Hi list,

this might be related to my other mail with the subject "Domain trust
and browsing users and groups problem".

We have a forest trust of two domains. One domain in US (us.root.prv)
running exclusively on Windows 2012 R2 and one in EU
(spreadshirt.private) running exclusively Sernet Samba 4.8.3-11. Both
domains run functional level "2008 R2". The trust validates successful
using "samba-tool domain trust validate" and in "Domains and
trusts".

Since establishing the trust, processing of group policies fail at all
Windows members in the Samba domain.

Running gpupdate /force produces this error:

C:\Users\tmu>gpupdate /force
Updating policy...

Computer Policy update has completed successfully.
User Policy could not be updated successfully. The following errors were
encountered:

The processing of Group Policy failed. Windows could not determine if
the user and computer accounts are in the same forest. Ensure the user
domain name matches the name of a trusted domain that resides in the
same forest as the computer account.

To diagnose the failure, review the event log or run GPRESULT /H
GPReport.html from the command line to access information about Group
Policy results.


In system event log this is logged:
Log Name:      System
Source:        Microsoft-Windows-GroupPolicy
Date:          7/5/2018 12:18:35 PM
Event ID:      1110
Task Category: None
Level:         Error
Keywords:
User:          SPREADSHIRT\tmu
Computer:      p223.spreadshirt.private
Description:
The processing of Group Policy failed. Windows could not determine if
the user and computer accounts are in the same forest. Ensure the user
domain name matches the name of a trusted domain that resides in the
same forest as the computer account.


Searching the internet to this error only points to a not running
netlogon service at Windows machine, which is the case here.
Removing the trust make GPOs working again at all Windows clients.

My question is: Are trusts ready for production?
>From my experience so far, they produce more trouble than gain.
Thank you for any insights.

Tino

Replying myself,

found this bug: https://bugzilla.samba.org/show_bug.cgi?id=11517

Looks like, it's known and being worked on it.
Sorry for the noise.

Tino