ZTNA & DFS/Namespaces for file shares

[imsail]

We're setting up ZTNA and one of the hurdles we have run in to is file shares - currently we're mapping network drives to our local domain name (eg \\contoso.lan\Share)

I've been able to verify share access via a specific server FQDN but when i try to set up "contoso.lan" as a FQDN address on the firewall (verified it appears in HOSTS file), access is lost which was expected. Contoso.lan resolves to the DCs and not the file share servers.

I didn't find any documentation or examples for this specific scenario and scratching my head how I could get this to work.

Has anyone run in to this or have any suggestions to look in to or try?

[Sx11]

Hi imsail,

please check the following guide related to your scenario:

https://docs.fortinet.com/document/fortigate/7.2.6/administration-guide/553746/ztna-access-proxy-wit...

Regards

[Pablito]

Any fix? Kdc proxy only works for shared folder not for dfs namespaces.

[andybarker]

I have the same issue and would like to hear the solution.

[David_Karpinski]

Hi folks,

I'm exploring solutions to this problem right now and would be grateful for any further insights.

DNS resolution and Namespace referrals currently don't work, though SMB and KDC are seamless.

Somehow forcing DNS over TCP and using another ZTNA destination for DNS, possible?

Thanks in advance.

[David_Karpinski]

Good news folks, I figured this out.

As the OP has stated, browsing to the domain root (\\domain.local for instance) needs to work as this is how the client attempts to get SMB referrals to the DFS root (\\domain.local\DFSRoot) and then further to actual shares (\\domain.local\DFSRoot\ShareName). The key is ensuring the client can resolve the DNS and talk to all of the SMB resources required.

In our network there are three domain controllers in the remote access site and one file server. The file server is the DFS root and was configured with AD integration as per MS best practice. Here's what we configured:

1) A DNS zone on the Fortigate for the forest root domain (domain.local for example).

2) DNS 'A' records for each of the relevant servers including all of the domain controllers in the site.

3) DNS 'A' record for the domain root '@' pointing to the PDC emulator. This one is critical.

4) Address objects of type FQDN for all of the servers in the full FQDN form (server01.domain.local for example).

5) This one is critical; an address object of type FQDN for the domain root (domain.local for example).

6) ZTNA server with a single server mapping of type TCP-forwarding. This mapping includes real server entries for all of your domain controllers. Critically, this also includes the address object for the domain root.

7) We've elected to add a second ZTNA server with a single server mapping of type TCP-forwarding. The second is specifically for the single file server but doesn't need to be separate.

8) We've configured a Kerberos KDC Proxy as per the Fortinet literature.

9) Of course, all of the FortiClient destinations for each of these resources, including the SMB domain root.

During testing we found that the ability to resolve the domain root via DNS and connect to the resolved servers via SMB are what matters. We also found that you may get an SMB referral to a different domain controller that the PDC emulator, for reasons I didn't bother to explore, so you'll need access to all of them. Once SMB is established to the domain controllers the client can request referrals to the DFS root and/or shares successfully.

I have a working config here, so I'm happy to answer any questions.