0

I'm posting this here after spending the last 5 days searching google, going thru test cases as well as analyzing network traffic in the event that someone could either point me in the right direction or understands what is going wrong.

Scenario:
We have a samba 4.7 server running on CentOS 7.5, locked to that specific OS version for driver compatibility and joined to a domain managed by RedHat IdM for a specific network (let's call it Zone B). On another network we have Windows 10 desktops, Ubuntu Desktops and Windows servers (some with shares) joined to an Active Directory domain (Let's call it Zone A). The two domains have a trust relationship so users from the AD zone can authenticate on servers housed within the RedHat IdM zone.

Samba ---> RedHat IdM <--- trust ---> Windows AD <--- Windows 10 / Ubuntu 18.04 / Windows Server

Problem at hand:
Windows clients from Zone A can't authenticate to the file shares on the samba server from Zone B, but Linux desktops from Zone A can. Windows clients can SSH to the samba server successfully using credentials from the AD forest.

Troubleshooting done so far:
1) lots of google search that leads nowhere so far. (maybe my googlefu being bad lately)

2) Trying a windows 10 client without any GPOs applied which resulted in a failure.

3) Comparing packet captures from:
Ubuntu Desktop 18.04 (Zone A) to Samba server (Zone B) [Success]
Windows 10 (Zone A) to Samba server (Zone B) [Failure]
Windows 10 (Zone A) to Windows Server file share (Zone A) [Success]

The outcome of the packet captures shows that the clients and server negotiate the protocol used, SMB3_02 in this case.

The Ubuntu client sends a session setup request to the samba server immediately after the negotiation while the Windows client just hangs and ends up sending a timeout a few seconds later.

When adding the Windows 10 to Windows Server in Zone A capture, the client and server negotiate the protocol (SMB3_02) and then Windows 10 sends the session setup request and successfully auth to the windows server.

Samba config global section (other sections only have path / ro settings):

[global]
   workgroup = ZONEB
   realm = ZONEB.LAB
   dedicated keytab file = FILE:/etc/samba/samba.keytab
   kerberos method = dedicated keytab
   log file = /var/log/samba/log.%m
   security = ads
   max protocol = SMB3_02
   create mask = 0660
   directory mask = 0770
0

Here is the solution in the event someone finds themselves in this situation.

The following DNS entry was not present and was never present on the IdM side.

_kerberos._tcp.ZONEA._sites.dc._msdcs.ZONEB.LAB

We added the entries for both ZONEB.LAB IdM DCs and everything started to work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.