You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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 ismichael-pc.ad.company.org
. It seems to me that the problem is around fqdn.js in the getFqdnForHostname and getFqdnForIpAddress methods.dns.lookup
on hostnamemichael-pc
results in a variety of ip addresses which I find when runningipconfig
. The first tried is the ipv4 address on my wifi adapter. However, running dns.reverse on that ip address does not return the fqdnmichael-pc.ad.company.org
. Instead, it returnssome-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 asad.company.org
which is why AD authentication does not work (my hypothesis). That leads toLogin 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.
The text was updated successfully, but these errors were encountered: