Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to connect to local database via NLTM on work's VPN #40

Open
mparq opened this issue May 16, 2017 · 1 comment
Open

Unable to connect to local database via NLTM on work's VPN #40

mparq opened this issue May 16, 2017 · 1 comment

Comments

@mparq
Copy link

mparq commented May 16, 2017

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.

@tvrprasad
Copy link
Owner

Thanks for sharing this. I'm aware of this issue and I don't know a way to fix this. If you have ideas, I'd love to hear. The solution would be for you to specify michael-pc.ad.company.org as the server name in connection config. Would that work for you? I could make a change to add an error message that suggests this.

btw, Tedious support for integrated auth is in a branch currently and not in the master. How did you end up with a setup that has the branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants