Thread Info
  • State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 24 subscribers
  • Views 23020 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ZTNA SMB Authentication with on-premise file server

b_192

Hi I am hoping someone may have come across or can point me in the right direction.

We have configured ZTNA and have been testing with web based SaaS apps and access to SMB shares to a file server on premise.

We have started to experience some issues with accessing the SMB shares as we receive messages with regards to authentication issues with the domain.

I believe this may be because the devices with the ZTNA agent installed do not have direct line of sight to the domain controllers.

I have added a number of ports via ZTNA to allow communications to the on premise domain controllers however this has not made any difference. I know you also need to allow a port range to the domain controllers however this is currently not possible within ZTNA but have seen on a forum that this is potentially coming Q2 this year.

I am just wondering if anyone else is using ZTNA to access on premise file shares? If so how do you handle authentication with the on premise domain controllers? Also how would you handle logging in if passwords etc need to get reset for a user? 


We are using Azure AD as the identity provider.
The devices with ZTNA agent installed are joined to local domain and not Azure AD joined currently.



This thread was automatically locked due to age.
Parents
  • 0

    Hello,

    We have heard of intermittent issues like this when the users are trying to access resources remotely and the domain controllers are not reachable. This is due to the fact that the ZTNA agent does not intercept DNS SRV records. One way to verify this is when you capture packets on all interfaces when you encounter this issue, the SRV records will not have any response. While we would roll out a fix to intercept SRV records, there is a temporary workaround you can try. On the public DNS server, create 4 DNS records of type SRV  with the following details:

    service : _gc._tcp.default-first-site-name._sites.dc._msdcs protocol: TCP port: 3268 target: external FQDN of the resource

    service:  _ldap._tcp.default-first-site-name._sites.dc ._msdcs protocol:TCP. port: 389 target: external FQDN of the resource

    service: _kpasswd._tcp.default-first-site-name._sites.dc._msdcs protocol:TCP. port: 464 target: external FQDN of the resource

    service: _kerberos._tcp.default-first-site-name._sites.dc._msdcs protocol:TCP. port: 88 target: external FQDN of the resource

    Do let us know if this works. Else, please share the SDU logs and the packet capture on all interfaces for us to debug further. 

    Regards,

    Tejas 

  • 0 in reply to Tejas Kashyap

    When is the fix being rolled out? We are having the Exact same issue and we are .com and this is inhibiting us from moving forward. we are currently trying to get away from VPN as well

Reply Children
No Data
Unfiltered HTML