-
Notifications
You must be signed in to change notification settings - Fork 933
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
Support for Windows Authentication _without_ a domain #1315
Comments
@chucker are you referring SQL Login authentication where SQL Server managed the Users and Logins? Or are you referring to local Windows user accounts? |
No, I'm referring to Windows user accounts. Specifically, we have a local AD, but several servers outside that domain. If i have an AD user |
If I VPN to work I am unable to use windows authentication to connect to our databases, because my machine is not on the domain. I have to use the runas command which is cumbersome, and on Linux I do not have the runas command! If there is a work around please let me know. |
This is probably related to #112 |
@aaomidi do you know if the auth changes we're planning in SqlClient would address this issue? |
Hmm, I'm not entirely sure. But potentially yes. I'll have to understand the scenario completely to be able to answer. |
(This scenario is indeed moot if we get #112 instead, which SSMS cannot do.) |
@chucker Are you looking through documentation only or you have an actual failing scenario that does not work as SSMS?
Based on my understanding, this scenario should work just fine same as SSMS. You should not be blocked by any scenario for Windows non-domain accounts when using "Integrated" authentication on Windows. |
Closing this issue due to inactivity. |
SQL Server Management Studio supports connection to a Windows server without the need for a domain on that end, as long as it has a matching username and password.
SQL Operations Studio, however, lists an AD domain as a prerequisite:
Presumably, SSMS achieves this through a different protocol (perhaps NTLM?), since there's apparently no actual Kerberos server on the other end in such a setup.
The text was updated successfully, but these errors were encountered: