Unable to connect to local database via NLTM on work's VPN #40
Description
Hello,
I figured I would post this issue here. I was running into this problem when working on an application for work which uses node, mssql and tedious driver which depends on sspi-client I believe. Apologize in advance for my lack of knowledge on the subject - I only dug around in the debugger and google as much as I can but I'm not too familiar with this stuff. I have a hypothesis about the problem, and I managed to hack-solve this issue for myself but I don't know what the wider solution would be.
os.hostname() on my computer returns my computer name e.g. michael-pc. My PC is domain-joined to my work network and the FQDN of my PC is michael-pc.ad.company.org. It seems to me that the problem is around fqdn.js in the getFqdnForHostname and getFqdnForIpAddress methods. dns.lookup on hostname michael-pc results in a variety of ip addresses which I find when running ipconfig. The first tried is the ipv4 address on my wifi adapter. However, running dns.reverse on that ip address does not return the fqdn michael-pc.ad.company.org. Instead, it returns some-other-host.other-domain.company.org.
Running ping -a 10.0.0.138 (my ipv4 address) resolves to the other domain when I'm connected via VPN and my computer's FQDN when I'm not.
However, some-other-host.other-domain.company.org is not the same domain as ad.company.org which is why AD authentication does not work (my hypothesis). That leads to Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 127.0.0.1] when attempting to connect to SQL Server using sspi-client.
If I modify the function getFqdnForIpAddress in fqdn.js to return my computer's FQDN instead of the VPN FQDN, things work fine.
I've spent a while debugging this issue so I don't have more time to look into it right now, but I may come back at a later date to debug further if I can.