Issue accessing file share in different AD forest

Question

Hello,

I am having trouble accessing a file share that is located in a different AD forest from my laptop with AlwaysONVPN configured.

I am able to access the file share without issue from a servers that are located in AD forest B and AD forest C network domain, but not from my VPN-connected laptop. I have confirmed that DNS resolution and network connectivity are working properly. Does anyone have any ideas on what could be causing this issue?

Attached for context is a diagram of the AD Forests setup:

Thanks in advance for any suggestions!

Answer 1

.........q

Answer 2

Hello,

Perform a packet capture using tools like Wireshark while attempting to access the file share as both an admin user and a regular user. Analyze the captured packets to compare the network traffic between the two scenarios. Look for differences in protocols used, authentication attempts, or any other relevant details.

---

If the Answer is helpful, please click "Accept Answer" and upvote it.

Answer 3

Hello

Apologies for the delayed response; this topic had been on the back burner due to other project commitments. I have been analyzing network traffic via Wireshark and observed that the client (a Windows 10 machine) is sending a TCP connection reset after negotiating the SMB protocol with the file share server. It appears that during this process, Kerberos authentication is reverting to NTLM, which is disabled on the file share server.

For reference, please find the captured logs below:

• 14 5.389257 10.90.3.108 10.90.9.24 SMB 127 Negotiate Protocol Request

• 15 5.524573 10.90.9.24 10.90.3.108 SMB2 306 Negotiate Protocol Response

• 16 5.524725 10.90.3.108 10.90.9.24 SMB2 326 Negotiate Protocol Request

• 17 5.559547 10.90.9.24 10.90.3.108 SMB2 366 Negotiate Protocol Response

• 18 5.566497 10.90.3.108 10.90.9.24 SMB2 536 Session Setup Request, INITATOR_NEGO, INITIATOR_META_DATA

• 19 5.601933 10.90.9.24 10.90.3.108 SMB2 153 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED

• 20 5.602598 10.90.3.108 10.90.9.24 SMB2 199 Session Setup Request, NTLMSSP_NEGOTIATE

• 21 5.637640 10.90.9.24 10.90.3.108 SMB2 463 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE

• 22 5.641356 10.90.3.108 10.90.9.24 TCP 54 53405 → 445 [RST, ACK] Seq=973 Ack=1073 Win=0 Len=0

• 23 5.644586 10.90.3.108 10.90.9.24 TCP 66 53406 → 445 [SYN] Seq=0 Win=65280 Len=0 MSS=1360 WS=256 SACK_PERM

When NTLM is enabled on the file share server, access is successful. However, I would like to know whether it would be possible to configure Kerberos authentication exclusively for resource access in an environment where there is a two-way transitive Active Directory (AD) trust?

Answer 4

If kerberos is not working and failing back to NTLM I would check SPN registration.

If machines are only EntraID joined do you have Kerberos Server configured? They get an Azure PRT token but what about Kerberos TGT, they will not have one available to access on-prem resources.

With Kerb Srv you get a partial TGT which you exchange with full TGT once you contact a DC trying to access on-prem resource.

You should configure Windows Hello for Business Cloud Kerberos Trust: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises