Thread Info
  • State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 23 subscribers
  • Views 12109 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.
  • 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

    Hi Tejas 

    Our internal domain is actually example.local so we are not able to make public DNS changes to this domain. Would you have any other suggestions or where can we share the SDU logs with yourself? If this is a known issue is there any timeframe on when a fix for this issue will be rolled out? 

  • 0

    I am currently in the same exact situation.  I have all our web services working but can’t get things such as file shares.  Group policy .  Password resets working.  Even though I have added all the ports into the ztna settings.  We also have .local vs .com.  Be good if sophos gave some information/documentation on this . As it’s currently the main hang up for us moving off of vpn 

  • 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

  • 0 in reply to Tejas Kashyap

    Hi Tejas,

    we also have the same issue. But we have an external DNS Server so i tried your sollution to test it. Unfortunately it doesnt work or I do something wrong. I created 4 SRV records like discribed. What should be the external FQDN Ressource? Our Domaincontroller? Our Domaincontroller as a ressource on ZTNA? Our ZTNA Gateway? Tested everything but nothing helps. 

    Wireshark logs something like this:

    14 4.995323 100.64.0.3 100.64.0.1 DNS 135 Standard query response 0xb281 No such name SRV _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.example.com

    When i try to make a SRV record for this: _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.example.com same error results.

    Any Help?

    Also do u know when the fix is rolled out?

  • 0

    Hi,

    i found a fix for me, which allows me to smb over ztna.
    This is a relative simple solution :D I put a Logonscript on every Client with GPO.

    This Logon Script looks like this:

    @echo off
    SET _cmd=net use
    FOR /f "tokens=2,3 delims= " %%G IN ('%_cmd%^|find "\\"') DO net use %%G /d && net use %%G %%H /user:example.com\%username%

    This makes the following:

    It list every SMB share mapped to the client, delete it and mapped it again. You have to change example.com to your domain. Et Voila, after restart all SMB shares are accessible.

    Hope this helps. (Only GPO isnt working so waiting for an update for ZTNA)

  • 0

    A new approach to this problem is now published. See: support.sophos.com/.../KB-000045614

    __________________________________________________________________________________________________________________

Unfiltered HTML