OpenZiti and Windows SMB Server

Support General Questions
1

This may not even be an applicable question here, but we'll give it a go.

Windows Edge Client (which implements the tunneler) creates NRPT records upon connection.
From what I have seen, NRPT records that have only a hostname (no domain suffix) do not work.
This is how many Windows SMB servers are accessed. I've tested, this and added one:

Name                             : {CB94958C-5414-41D6-9D74-B6C2F2C26788}
Version                          : 2
Namespace                        : {hostname}
IPsecCARestriction               :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessProxyName            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      : 100.64.0.2
DnsSecEnabled                    : False
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         :
DnsSecValidationRequired         :
NameEncoding                     : Disable
DisplayName                      : ziti-edge-tunnel:hostname
Comment                          : Added by ziti-edge-tunnel

But, unfortunately, it cannot be resolved.


PS C:\Users\jagau> Resolve-DnsName hostname
Resolve-DnsName : hostname : The filename, directory name, or volume label syntax is incorrect
At line:1 char:1
+ Resolve-DnsName hostname
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (hostname:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : ERROR_INVALID_NAME,Microsoft.DnsClient.Commands.ResolveDnsName

I can access by the assigned IP address.

Does anyone know if this is an NRPT limitation? I've tried on a couple machines to make sure that it wasn't just a specific machine I was testing with.

Thanks!

2

Unfortunately, ZDEW does not resolve hostname-only intercepts at this time. It's not a limitation of the NRPT per-se, I don't believe. It's been a while since I last tried it but if memory serves, the problem came down to windows itself and configurations. It wasn't deemed "important enough of a problem to solve" at the time. As we only have so much time to put towards features, it just hasn't been made a priority.

When I last looked this came down to a few issues and I personally don't remember the exact issue. One was with WINS -- the old style DNS-like thing windows had/has. I dunno if that's exact the same as "NetBIOS" but that was yet another wrinkle, i think? (it's been a minute since I researched all this). DHCP is another problem because some applications, depending on what system calls they, end up appending the default domain to a DNS request which just confuses lots of people because now in your intercept, you, the admin need to know the domain that will be appended at the client side which is "not great" for all situations... This is why I set my local dhcp server to return ".from-dhcp" so that I could find these types of issues....

So -- the short answer is "it's complicated" and because it's so hard to get it exactly correct, the easier answer is to simply "not support naked hostnames" and require all intercepts be FQDN (contain at least one period)...

That's the history of this decision, as I recall it today! :slight_smile: Someone else in the community might remember additional detail or correct me lol...

3

Thanks for the answer! Certainly no pressure to implement. Everything (even Windows SMB) can be accessed by a FQDN. Windows SMB gets interesting because you have to access it with it's actual applied name.

WINS and NetBIOS are some pretty dated technologies and even MS stopped using NetBIOS to access SMB shares some years ago and now uses 445 strictly. (instead of 138/139 or whatever it was)