Hi everyone
Today I wanted to discuss a bug I encountered that got some major impact. The setup is Windows Server 2019 and some Windows 10 client. The bug wasnt present when the server were on 2008R2. The problem seen was when I edit a file over VPN on the file share, the file lost it’s security acl to become orphan and it disappear from the user view at the same time.
It’s a strange bug as the user can see only the folder where he got access to, but when the bug appear the file lost it security at all. Only an admin can take back the file ownership back.
From my research the error seem related to the Palo Global Protect VPN’s software that badly redirect DNS query, and do error out on ldap/kerberos lookup for the domain name. Which seem to lead to authentification error, even if the share is already open.
The symptom I had was;
- Only able to map the network drive by the IP.
- Such error flood inside wireshark for the remote computer;
- DNS QUERY for _ldap._tcp.dc._msdcs.domain fail. (not found)
Such DNS entry can be validated that way;
nslookup
set type=all
_ldap._tcp.dc._msdcs. Domain_Name
Validating the DNS entry confirm it work on the LAN, but not from the VPN’s endpoint.
What I discovered is for these clients the mapping was working correcty by using the FQDN directly, not the DFS nameshare or the hostname of the server, really the FQDN, like \\server.domain.com.
The bug seem really related to the globalprotect vpn software, but with this small tip atleast you can bypass that bug.
* Some reference for the nslookup comand line: How to verify that SRV DNS records have been created for a domain controller
Phil’s Blog | IT to the core ! 