I have always thought that in order to connect to SQL server using windows authentication with explicitly specified credentials, you must LogonUser, Impersonate, then connect.
It seems to me that this link suggests that it's possible to connect to SQL server without all this hassle, simply by specifying "uid=...;pwd=..." in connection string. I tested this method just to be sure it doesn't work, and - lo and behold - it didn't. If that blog post wasn't on msdn.com, I would have just dismissed it as noob talk, but it is.
Does anyone have an idea what am I missing?
EDIT1: Many respondents misunderstood what I was referring to. Here's a copy/paste of what I was talking about. It's not integrated SQL, nor it's an ASP.NET impersonation made by IIS:
string sql4 = String.Format(
#"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);
// Database + Windows Authentication + Username/Password
There are two distinct kinds of security with SQL Server. "Windows Authentication", and "SQL Server Authentication". When you see uid and pwd you're seeing the latter. The uid in this case is not a Windows principal - the OS knows nothing about it.
So the answer to your question is, no, you can't pass Windows user name and password in the connection string to log in to SQL Server.
It depends - if you connect from a command-line or Winforms app DIRECTLY to your SQL Server, you EITHER specify "Integrated Security=SSPI;" and then use your Windows credentials as logon credentials, OR you specify "user id=....;pwd=....." - but that's then a SQL logon - NOT your Windows logon.
You mention "impersonate and then connect" - that seems to indicate ASP.NET - that's a totally different story again. If you impersonate, then you're basically using your Windows credentials, e.g. the web server will "impersonate" you and log on as you (using your Windows credentials). In that case, again, no "uid=....;pwd=....." needs to be specified (if it is, it will be ignored).
As that link you mentioned clearly shows - if you can connect directly, and you specify "Integrated Security=SSPI;", then this takes precedence over any uid=...;pwd=.... which you might also specified and logs you in using your Windows credentials; those extra uid=...;pwd=.... pieces are ignored.
Marc
The article and point in question relates to SQL security, not integrated security. You can pass the credentials for a SQL user and log in in this manner if SQL authentication (mixed mode) is enabled. If the SQL server is set up to use integrated security only then this will not work. It will also not work to allow logging in using Windows logon credentials.
In our shop, we routinely use connection strings like you describe. No problemo. But your sql server database must be set up to use sql security, not windows authentication.
A sample connection string (from web.config) in our app looks like:
<connectionStrings>
<add name="ConfigurationData" connectionString="server=DevServer;
database=travel_expense_management_dv;uid=userid;pwd=password!;"
providerName="System.Data.SqlClient" />
</connectionStrings>
On the other hand, the DBA guru for our shop set me up a personal database on the main server that had integrated security with my Windows logon. I didn't need uid and pwd because it took my authentication info from context.
Yes, as you say, the article mentions this:
string sql4 = String.Format(#"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server); // Database + Windows Authentication + Username/Password
But if you carefully read few lines later, it says this:
string sql4 -> Logs in with Windows login, ie. takes precedence over the username/password.
:)
This is very old but maybe someone has the same issue.
You can connect using WindowsAuthentication and specifying user id and password on your connection string, but not on every device. You can achieve this for example on WinCE devices (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).
I don't know if you can do the same thing on other OS just with the connection string (without doing the impersonation thing).
Hope it helps.
just a contribution also for some who was still encountering problem like this. Based on my experience if you don't specify any user/password in you connectivity it will automatically connect to db using windows authentication. Meaning it will get the userid and it's credential of the user who logged on to the machine. The system will allow you to connect to database if it identifies that your userid exist/created in the database. But once you specify your userid and password in your connectivity it bypass the windows authentication and use sql server authentication instead.
Related
I am trying to host a SQL server database, but whenever I try to connect to it I get this error:
The login is from an untrusted domain and cannot be used with Windows
authentication
I am connecting through Matlab using the following command:
conn = database('Clinical_Data','DoyleLab07\Acc','','com.microsoft.sqlserver.jdbc.SQLServerDriver','jdbc:sqlserver://DOYLELAB07\SQLEXPRESS:54287;database=Clinical_Data;integratedSecurity=true;').
Connecting to the database using matlab worked fine as long as I was using matlab on the computer which I was using to host the server. However, when I use another computer and the same Matlab command I get the error I showed above.
When I look under control panel\system. I notice that no domain is listed on my host PC or the PC I am using to connect to the host, but both computers are in the same workgroup. Would I be able to fix my problem by creating a domain and adding the foreign PC and the host to that domain? If so, how can this be accomplished?
Any suggestions will be very much appreciated.
Thank you for reading my post.
Getting rid of Integrated Security=true worked for me.
In order to use Windows Authentication one of two things needs to be true:
You are executing from the same machine as the database server.
You have an Active Directory environment and the user the application is executing under (usually the logged in user) has rights to connect to that database.
If neither of those are true you have to do one of two things:
Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
Change SQL server to use both Windows and SQL Server accounts.
By FAR the easiest way is to change SQL Server to use both Windows and SQL server accounts. Then you just need to create a sql server user on the DB server and change your connection string to do that.
Best case option 1 will take a full day of installation and configuration. Option 2 ought to take about 5 minutes.
If your SQL Server is on one domain controller and you are trying to connect to it from another domain controller then you will get this error when
IntegratedSecurity = true;
This will happen even if you include a valid SQL Server username and password in your connection string as they will automatically be over-written with your windows login and password. Integrated security means simply - use your windows credentials for login verification to SQL Server. So, if you are logged in to a different domain controller then it will fail. In the case where you are on two different domain controllers then you have no choice but to use
IntegratedSecurity = false;
Now, when Integrated security is false SQL Server will use the SQL Server login and password provided in your connection string. For this to work, the SQL Server instance has to have its authentication mode configured to mixed mode, being, SQL Server and Windows Authentication mode.
To verify or change this setting in SQL Server you can open the SQL Server Management Studio and right-click on your server name and then select Properties. On the pop-up that appears select Security and you will see where to alter this setting if you need to.
I've had this same issue when using DNS aliases and hosts files to connect to a machine using a different domain name.
Say you have a SQL server called sql1 on mydomain.com - which is an Active Directory domain - and you also have a DNS zone for mydomain.net, and - for consistency - you set up a DNS alias (CNAME) record for database.mydomain.net --> sql1.mydomain.com
You'll be able to connect to sql1.mydomain.com using Windows integrated security, but won't be able to connect to database.mydomain.net even though it's the same server because the domain name doesn't match your AD domain.
This error message can also occur if the account you are using to access the SQL server is locked out by the domain.
I was facing the issue while connecting to SQL Always On Listener. Disabling the loop back check resolved the issue.
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck”
Set this value to 1
https://blog.sqlauthority.com/2017/04/18/sql-server-login-failed-login-untrusted-domain-cannot-used-windows-authentication/
Why not use a SQL Server account and pass both the user name and password?
Here is the reason why.
In short, it looks like you have an authentication issue.
The problem with workgroups is there is no common Access Control List like Active Directory (AD). If you are using ODBC or JDBC, the wrong credentials are passed.
Even if you create a local windows account (LWA) on the machine (SE) that has SQL Express installed (SE\LWA), the credentials that will be passed from your client machine (CM) will be CM\LWA.
As mentioned here, you might need to disable the loopback
Loopback check can be removed by adding a registry entry as follows:
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck” Set this value to 1
If you using windows authentication make sure that password of the user hasn't expired. An expired password can explain this error. This was the problem in my case.
Same Error with Connection String in Visual Studio dev environment
Our development database server was recently given a self-signed certificate so it automatically became untrusted. This resulted in the login error cited above. I added TrustServerCertificate=True to my connection string and it works now.
"Server=TheServerAddress; Database=TheDataBase; User Id=TheUsername; Password=ThePassword; TrustServerCertificate=True"
NOTE: This certificate configuration is not recommended for production environments.
In my case the Aliases within SQL Native Client 11.0 Configuration were pointing to invalid server/IP. Once updated it worked correctly.
To check:
1. Start "SQL Server Configuration Manager"
2. Navigate to "SQL Native Client 11.0 Configuration" and then "Aliases"
3. Ensure "Alias Name" and "Server" match correctly for TCP/IP
Following worked for me to get access from another machine to SQL Server using Windows Authentication. This approach may be useful only in development/test environment. E.g. you need to update password manually once you change it on your working machine.
On machine with SQL Server go to Control Panel and add new Windows User with same username and password as is on your working machine. Then create SQL Server login for this user:
CREATE LOGIN [SQLSERVERHOST\myuser] FROM WINDOWS;
Now you can use this login for Windows Authentication.
If you receive error 'The login is from an untrusted domain', this may mean that you changed password on your working machine and now need to update password on SQL Server machine.
Just adding my suggestion for a resolution, I had a copy of a VM server for developing and testing, I created the database on that with 'sa' having ownership on the db.
I then restored the database onto the live VM server but I was getting the same error mentioned even though the data was still returning correctly. I looked up the 'sa' user mappings and could see it wasn't mapped to the database when I tried to apply the mapping I got a another error "Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405". so I ran this instead
ALTER AUTHORIZATION ON DATABASE::dbname TO sa
I rechecked the user mappings and it was now assigned to my db and it fixed a lot of access issues for me.
Joining a WORKGROUP then rejoining the domain fixed this issue for me.
I got this error while using Virtual Box VM's. The issue started to happen when I moved the VM files to a new drive location or computer.
Hope this helps the VM folks.
We now use a privileged account management solution that changes our passwords regularly. I ended up receiving this error after my password was changed. Closing and re-opening SSMS with the new password resolved my issue.
I started to get this error when i tried to login to SSMS using 'windows Authentication'. This started to happen after i renamed the Windows SQL server. I tried everything to resolve this error and in my particular case changing the machine names in the 'hosts' file to reflect the name SQL server name change resolved the issue. C:\Windows\System32\Drivers\etc\hosts
I had this problem because we where using a DNS name from an old server, ponting to a new server. Using the newserver\inst1 address, worked. both newserver\inst1 and oldserver\inst1 pointed to the same IP.
Yet another thing to check:We had our nightly QA restore job stop working all of a sudden after another developer remoted into the QA server and tried to start the restore job during the middle of the day, which subsequently failed with the "untrusted domain" message. Somehow the server pointed to be the job's maintenance plan was (changed?) using the ip address, instead of the local machine's name. Upon replacing with the machine name the issue was resolved.
TLDR: Changing the DNS server to the loop back address worked for me.
I am working in VirtualBox and had setup two Windows Server 2016 instances. Server A is configure as a Domain Controller and Server B as an SQL Server. After adding Server B to the domain I cold not connect to with Management Studio from Server A. I was getting the "The login is from an untrusted domain and cannot be used with Windows authentication".
My initial configuration had the server getting its IP from the VirtualBox DHCP server.
I changed this to use static IP and entered the 127.0.0.1 address in the Primary DNS and this worked for me.
Hope this helps someone passing by.
I enabled Trust Server Certificate in the Connection Properties and it worked for me
You might find out that you have more than one connection string, and you forgot to change the other one to Integrated Security to false. It happened to me. This answer might help someone.
I was focusing on the web config and the access rights, after a long hustle i remembered that I have another connection string in one of my classes for the emails, I had to change the connection string on the class to use the web config one.
i removed Integrated Security=true and Trusted_Connection=True both of them , worked for me..
In .net Core also you may get this error if Trusted_Connection=True;
Is set. Sample setting in appsettings.json
ConnectionStrings": {
"DefaultConnection": "Server=serverName; Database=DbName; uid=userId; pwd=password; MultipleActiveResultSets=true"
},
Sometime SSMS hang and close all of sudden ,then you get below error when you reconnect to SSMS
i) The Login is From an Untrusted Domain and Cannot be Used with Windows Authentication
OR
ii) The target principal name is incorrect .Cannot generate SSPI context.
In both cases RESTART YOUR MACHINE.
I also had a similar error but then I realised I just had changed the password for my system which caused this error.
To resolve it , I simply logged out of the current session and logged in again and this time
Please Use This Connection URL It's Work Fine
"Data Source=Your IP Address;Initial Catalog = DatabaseName;User ID =sa;Password =your PassWord;TrustServerCertificate=True"
Example : "Data Source=192.168.150.122;Initial Catalog=StudentDb;User ID=sa; PassWord=123;TrustServerCertificate=True"
If you have two servers on the same domain (eg. APP and DB), you can also use Windows Authentication between the app and MSSQL by setting up local users on both machines that match (same username and password). If you don't have the passwords matched up, it can throw this error.
Following was working for me. hope this helps you
<add name="getconn" connectionString="Data Source=servername;Initial Catalog=DBName;Persist Security Info=True;User ID=sa;Password=***" />
I have a web site and I'm trying to setup a DSN instead of using a connection string because it seems more secure.
The following connection string works fine in my site:
"Server=servername; database=mydb; user id= web.account; password=PassW0rd!; Integrated Security=SSPI"
However, when I try to set up a DSN (using the 64-bit odbc admin) I get the following error:
Connection failed:
SQLState: '28000'
SQL Server Error: 18456
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'web.account'
Keep in mind, I'm using the same account and password I use in the connection string (which works). It's weird too because the error occurs right after I click 'Next' on the "How should SQL Server verify the authenticity of the login ID?" page.
It seems like the odbc admin does not even try to connect to the server to verify the credentials. What can I check to prove this / How can I fix this?
Things I've tried:
I have checked the server authentication mode, as proposed in other solutions, and that is set to "SQL Server and Windows Authentication mode", as it should be.
I have tried creating both a User and System DSN - both get the same error, this seems like further evidence that it's not trying to connect to the server to check the credentials.
I have tried the same DSN creation on multiple servers, all have the same problem. Is it possible the SQL Server is refusing these types of connections?
UPDATE 1:
The DBA just told me that the web.account is actually a Windows account, not an SQL account. I guess that's why the odbc isn't working, because it doesn't try to connect as a different windows user, only as the current windows user. So now the question is, how do I set up a DSN with a different windows account? Or, is that even possible?
This post has a response that says DSNs setup with NT authentication are specifically for the entire system, not a specific account, so a runas command could be used from cmd, like so:
runas /netonly /user:domain\web.account "C:\Windows\SysWOW64\odbcad.exe"
It will then ask you for the web.account password. Then you can create a DSN, and this should work.
UPDATE: I had to add the web.account user to my Administration Group using this fine how-to. Then I had to run cmd as my elevated account. Then ran the runas command I showed above. Then, I was finally able to create a non-native DSN, which allowed me to connect to the Data Server as a different Windows user.
Still waiting for DBA to check the logs to say this actually worked or not, but I feel pretty good about it. Will update after confirmation.
Try the following:
Data Source=servername;Initial Catalog=mydn;Persist Security Info=True;User ID=web.account;Password=Passw0rd
This is what I use to connect.
I've got this error:
A connection was successfully established with the server, but then an error occurred
during the login process. (provider: Shared Memory Provider, error: 0 - No process is
on the other end of the pipe.)
(Microsoft SQL Server, Error: 233)
I know, there are similar questions on this site, and the answer is, to enable TCP/IP and pipes.
But I enabled both, and still doesn't work:
I am using Microsoft SQL Server 2012 and the user has full permissions.
The server was set to Windows Authentication only by default. There isn't any notification, that the origin of the errors is that, so it's hard to figure it out. The SQL Management studio does not warn you, even if you create a user with SQL Authentication only.
So the answer is: Switch from Windows to SQL Authentication:
Right click on the server name and select properties;
Select security tab;
Enable the SQL Server and Windows Authentication mode;
Restart the SQL Server service.
You can now connect with your login/password.
Here are the directions by Microsoft: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/change-server-authentication-mode?view=sql-server-ver15
To solve this, connect to SQL Management Studio using Windows Authentication, then right-click on server node Properties->Security and enable SQL Server and Windows Authentication mode. If you're using 'sa' make sure the account is enabled. To do this open 'sa' under Logins and view Status.
If this didn't work, you may need to reinstall SQL Server
Also you can try to go to services and restart your Sql server instance
So, I had this recently also, for integrated security, It turns out that my issue was actually fairly simple to fix but mainly because I had forgotten to add "Trusted_Connection=True" to my connection string.
I know that may seem fairly obvious but it had me going for 20 minutes or so until I realised that I had copied my connection string format from connectionstrings.com and that portion of the connection string was missing.
Simple and I feel a bit daft, but it was the answer for me.
Another reason for this error could be incorrect or non-existent database name.
Forcing the TCP/IP connection (by providing 127.0.0.1 instead of localhost or .) can reveal the real reason for the error. In my case, the database name specified in connection string was incorrect.
So, here is the checklist:
Make sure Named Pipe is enabled in configuration manager (don't forget to restart the server).
Make sure the database you are connecting to exists.
Make sure SQL Server Authentication (or Mixed Mode) is enabled.
Please check this also Also check in configuration TCP/IP,Names PipeLine and shared memory enabled
If you are trying to login with SQL credentials, you can also try changing the LoginMode for SQL Server in the registry to allow both SQL Server and Windows Authentication.
Open regedit
Go to the SQL instance key (may vary depending on your instance name):
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQLServer\
Set LoginMode to 2
Restart SQL service and SQL Server Management Studio and try again.
I face this issue for the second time and all previous answers failed, fortunately the following request do the job:
Alter login [user] with CHECK_POLICY = OFF
go
Alter login [user] with CHECK_POLICY = ON
go
For me the password expired for my login user, and i got the same exception.
Then i login with Windows Authentication mode and change the password for the associated user, and it solved my problem.
Yup, this error might as well be "something failed, good luck figuring out what" - In my case it was a wrong username. SQL Server 2019 RC1.
Had this error too, the cause was simple, but not obvious: incorrect password. Not sure why I didn't get just "Login failed" from freshly installed SQL 2016 server.
I have the same proplem
"A connection was successfully established with the server, but then an error occurred
during the login process. (provider: Shared Memory Provider, error: 0 - No process is
on the other end of the pipe.)"
My connection is:
server=POS06\SQLEXPRESS; AttachDbFilename=C:...\Datas.mdf;Initial Catalog= Datas; User ID= sa; Pwd=12345; Connect Timeout=10;
But My SQL is POS06\MSQL2014
Change the connection string to
server=POS06\MSQL2014 ; AttachDbFilename=C:...\Datas.mdf;Initial Catalog= Datas; User ID= sa; Pwd=12345; Connect Timeout=10;
it worked.
Always try to log in using those credentials with SQL Management Studio. This might reveal some more details that you don't get at runtime in your code.
I had checked the SQL + Windows authentication, restarted the server but still no luck.
After trying to log in using SQL Management, I got this prompt:
Somehow the password had expired although the login was created just minutes before. Anyway, new password set, connection string updated and all's fine.
This might help others. After writing my db routines at home, all working fine. Brought it to work and got this error as well. Might assert same error, different reason. I mistyped the database name when fixing up my code. Ooohh! More coffee ;) Looking back now, kind of makes sense in my case the login/user was good (an admin account) but with a bad database name, there was nothing on the end of the pipe. Why not say "Database does not exists...? And be clear.
make sure that you have specified user in Security-> Logins, if no - add it and try again.
Follow the other answer, and if it's still not working, restart your computer to effectively restart the SQL Server service on Windows.
In my case the database was restored and it already had the user used for the connection. I had to drop the user in the database and recreate the user-mapping for the login.
Drop the user
DROP USER [MyUser]
It might fail if the user owns any schemas. Those has to assigned to dbo before dropping the user. Get the schemas owned by the user using first query below and then alter the owner of those schemas using second query (HangFire is the schema obtained from previous query).
select * from information_schema.schemata where schema_owner = 'MyUser'
ALTER AUTHORIZATION ON SCHEMA::[HangFire] TO [dbo]
Update user mapping for the user. In management studio go to Security-> Login -> Open the user -> Go to user mapping tab -> Enable the database and grant appropriate role.
In my case: Assign a sysadmin role to the user.
Login as windows authenticated user
Go to: Security->Login->Right click user->Assign server role as sysadmin
In my case, login works fine remotely, via VPN. But connecting from the server where sql server was installed, it failed.
Turns out, the instance name is not the default eg. SQLEXPRESS. Hence, it needs to be explictly specified when connecting.
Server name: .<instance_name>
eg. ".\I01"
I don't have to do this if I'm connecting remotely, just <server_hostname>,<port_number>
I'm having to support multiple database types for my tenant-enabled web application. Among others, I have successfully supported Microsoft's SQL Server, by using the net.sourceforge.jtds.jdbc.Driver class with a connection String like "jdbc:jtds:sqlserver://192.168.1.189:1433/ApplicationName". This works, but it requires that the user explicitly defines a user in the SQL Server instance and enables SQL Server authentication.
Now, inevitably, requirements changed, and we're supposed to support connecting to SQL Server via Windows Authentication. Evidently this requires some sort of change to the connection string, since the data base server must somehow be able to distinguish whether the credentials passed into the data base connection are for a user defined in the SQL Server installation or in the Windows OS. But what is it?
Acting on advice from the internet, if progressed as far as extending the connection string with ;useNTLMv2=true;domain=WORKGROUP. That seems to make the data base server aware that I want to authenticate as a Windows user, but the actual log-in fails with
The login is from an untrusted domain and cannot be used with Windows authentication. (code 18452, state 28000)
Now im my testing set-up, both the J2EE app and the SQL server instance are in fact on the same machine (although in production they may not be), and still this computer isn't trusted enough to log on to itself? Evidently I'm missing a big part of the puzzle here. What does one have to do to convince an SQL Server instance that the user who started it can in fact log on to it via JDBC?
Edit
Since we have already sunk too much unsuccessful effort trying to integrate our web application with a full Microsoft infrastructure stack (SQL Server, Active Directory, Domain Name Service...), I have to restrict this question:
Does anyone know a way to access an SQL Server installation with a user account defined as a "Windows User" via JDBC form a J2EE application, without having to use Active Directory, a Windows machine running the web application and a proprietary DLL? The bounty is for any solution of that sub-problem. The entire problem is clearly too broad to be answered in one forum post.
I ran into the error
The login is from an untrusted domain and cannot be used with Windows
authentication
when a 2012 SQL Server DB instance was recently upgraded to 2016. In order to use AD based authentication with the JTDS driver and SQL Server 2016, it seems necessary to specify both the useNTLMv2=true and the domain=example.com suffix in order to establish a connection. The name of the domain is absolutely necessary and I confirmed that through testing. This is with JTDS driver version 1.3.1.
Example of a working connection string using AD based authentication to SQL Server 2016 DB with JTDS 1.3.1:
jdbc:jtds:sqlserver://sqlserver2016db.example.com/MY_DB_NAME;domain=example.com;prepareSQL=2;useNTLMv2=true
UPDATE
Recently (due to the pandemic lockdown), I found myself also having to connect to SQL Server using Windows authentication from a non-domain computer (over VPN). This can be accomplished by starting the Windows process initiating the SQL Server connection, e.g. Eclipse / Spring Tool Suite, with the following command:
C:\Windows\System32\runas.exe /netonly /user:domain\user "path_to_executable.exe"
Source: https://www.mssqltips.com/sqlservertip/3250/connect-to-sql-servers-in-another-domain-using-windows-authentication/
In discovering that gem, I also discovered that encryption needed to be used. Here are the settings I'm using (in addition to now running the executable with /netonly and a domain account):
spring.datasource.url=jdbc:jtds:sqlserver://fqdn_of_server_including_domain/DBNAME;domain=mydomain;useNTLMv2=true;ssl=require;prepareSQL=2;
spring.datasource.username=domainaccountname_without_domain_prefix
spring.datasource.password=password
spring.datasource.testOnBorrow=true
spring.datasource.hikari.connection-test-query=SELECT 1
spring.jpa.database-platform=org.hibernate.dialect.SQLServerDialect
What you describe certainly appears to be feasible. I have SQL Server 2008 R2 Express running on a stand-alone server and I was able to connect using a Windows username/password on that server via jTDS 1.3.1 from a separate Windows machine and from an Xubuntu 14.04 box.
On the machine running SQL Server I created a Windows user named 'kilian'. In SQL Server itself I created a SQL Login for NT AUTHORITY\Authenticated Users. Then in the database (named 'myDb') I created a User named 'AuthenticatedUsers' for that SQL Login. Just to keep things simple I gave that user db_owner rights on the database.
There is no SQL Login for 'kilian' and no database User with that name.
Then, from the other two machines (the Windows workstation and the Xubuntu box) I just ran this:
package com.example.jtdstest;
import java.sql.*;
public class JtdsTestMain {
public static void main(String[] args) {
try (Connection con = DriverManager.getConnection(
"jdbc:jtds:sqlserver://192.168.1.137:52865/myDb" +
";domain=whatever",
"kilian",
"4theBounty")) {
try (Statement s = con.createStatement()) {
String sql = "SELECT LastName FROM Clients WHERE ID=1";
try (ResultSet rs = s.executeQuery(sql)) {
rs.next();
System.out.println(rs.getString("LastName"));
}
}
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
}
Additional notes:
I did not have to include useNTLMv2=true. I was able to connect with or without that parameter.
I did have to include domain= to tell the SQL Server not to use SQL authentication, but the actual value I supplied made no difference. (I literally used 'whatever', which was not the name of the server or the name of the workgroup to which it belongs.)
Alternative Method
The alternative solution is to utilize integrated security. This enables your application to connect to the database as the user in which the application is currently running as. This is enabled by adding integratedSecurity=true; into the connection string properties. If you run into any trouble, make sure the sqljdbc_auth.dll is accessible via classpath or within your app library.
Security Note
You're probably already aware, but just have to say make sure not to grant access to "Authenticated Users" to your database as previously suggested as part of the demonstration. Identify which user account your application runs as and grant access to only that specific user in your database server.
Sources / Additional Info
MSDN Doc on JDBC Connection String Configuration (http://technet.microsoft.com/en-us/library/ms378428(v=sql.110).aspx)
The main problem is the windows authentication with a full java solution (no DLL). So you could use one of the libs below:
NTLM authentication: http://ioplex.com/jespa.html
spring based Kerberos authentication: http://projects.spring.io/spring-security-kerberos/
another integrated windows auth lib is SPNEGO (don't know much about this one)
So once your app is authenticated with one of the lib above, your JDBC should run fine using "integratedSecurity=true;" and if needed "authenticationScheme=JavaKerberos".
Firstly you should write the jdbc connection like this:
String url ="jdbc:sqlserver://PC01\inst01;databaseName=DB01;integratedSecurity=true";
then
you need to enable the SQL Server TCP/IP Protocol in Sql Server Configuration Manager app. You can see the protocol in SQL Server Network Configuration.
I can see two possibilities,
1. You are using a local system account which the server won't understand
In this case, switch to a domain account.
Windows authentication has different credential requirements and you might not be meeting those.
In this case try changing the password to match the requirements.
It is very well possible that both are happening.
see this other SO post that describes how to connect to a SQL Server with Windows Authentication from a Linux machine through JDBC
This is my NiFi setup for jTDS driver:
Database Connection URL: jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name
I didn't need to add useNTLMv2=true, but most people need to, so if it doesn't work you can try also:
jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name;useNTLMv2=true
Database Driver Class Name: net.sourceforge.jtds.jdbc.Driver
Database User: domain_user_name (**without** #domain)
Password: domain_password
Validation query: select 1
One of the possible reasons for this error to appear is when you configure you data source to use windows authentication and SQL Server is using Extended Protection mode together with SSL (i'm not sure if SSL is required though). This mode requires the client to send additional information - signed service principal name (SPN) and channel binding token (CBT). See more information about Extended Protection Mode here. Currently both JTDS JDBC and Microsoft JDBC drivers do not support this mode. I couldn't find an official statement from JTDS, but there is an open ticket for Microsoft drivers.
In order to configure Extended Protection mode, go to SQL Server Configuration Manager, select properties on SQL Server Network Configuration -> Protocols for %your instance% and change Extended Protection option.
I am trying to host a SQL server database, but whenever I try to connect to it I get this error:
The login is from an untrusted domain and cannot be used with Windows
authentication
I am connecting through Matlab using the following command:
conn = database('Clinical_Data','DoyleLab07\Acc','','com.microsoft.sqlserver.jdbc.SQLServerDriver','jdbc:sqlserver://DOYLELAB07\SQLEXPRESS:54287;database=Clinical_Data;integratedSecurity=true;').
Connecting to the database using matlab worked fine as long as I was using matlab on the computer which I was using to host the server. However, when I use another computer and the same Matlab command I get the error I showed above.
When I look under control panel\system. I notice that no domain is listed on my host PC or the PC I am using to connect to the host, but both computers are in the same workgroup. Would I be able to fix my problem by creating a domain and adding the foreign PC and the host to that domain? If so, how can this be accomplished?
Any suggestions will be very much appreciated.
Thank you for reading my post.
Getting rid of Integrated Security=true worked for me.
In order to use Windows Authentication one of two things needs to be true:
You are executing from the same machine as the database server.
You have an Active Directory environment and the user the application is executing under (usually the logged in user) has rights to connect to that database.
If neither of those are true you have to do one of two things:
Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
Change SQL server to use both Windows and SQL Server accounts.
By FAR the easiest way is to change SQL Server to use both Windows and SQL server accounts. Then you just need to create a sql server user on the DB server and change your connection string to do that.
Best case option 1 will take a full day of installation and configuration. Option 2 ought to take about 5 minutes.
If your SQL Server is on one domain controller and you are trying to connect to it from another domain controller then you will get this error when
IntegratedSecurity = true;
This will happen even if you include a valid SQL Server username and password in your connection string as they will automatically be over-written with your windows login and password. Integrated security means simply - use your windows credentials for login verification to SQL Server. So, if you are logged in to a different domain controller then it will fail. In the case where you are on two different domain controllers then you have no choice but to use
IntegratedSecurity = false;
Now, when Integrated security is false SQL Server will use the SQL Server login and password provided in your connection string. For this to work, the SQL Server instance has to have its authentication mode configured to mixed mode, being, SQL Server and Windows Authentication mode.
To verify or change this setting in SQL Server you can open the SQL Server Management Studio and right-click on your server name and then select Properties. On the pop-up that appears select Security and you will see where to alter this setting if you need to.
I've had this same issue when using DNS aliases and hosts files to connect to a machine using a different domain name.
Say you have a SQL server called sql1 on mydomain.com - which is an Active Directory domain - and you also have a DNS zone for mydomain.net, and - for consistency - you set up a DNS alias (CNAME) record for database.mydomain.net --> sql1.mydomain.com
You'll be able to connect to sql1.mydomain.com using Windows integrated security, but won't be able to connect to database.mydomain.net even though it's the same server because the domain name doesn't match your AD domain.
This error message can also occur if the account you are using to access the SQL server is locked out by the domain.
I was facing the issue while connecting to SQL Always On Listener. Disabling the loop back check resolved the issue.
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck”
Set this value to 1
https://blog.sqlauthority.com/2017/04/18/sql-server-login-failed-login-untrusted-domain-cannot-used-windows-authentication/
Why not use a SQL Server account and pass both the user name and password?
Here is the reason why.
In short, it looks like you have an authentication issue.
The problem with workgroups is there is no common Access Control List like Active Directory (AD). If you are using ODBC or JDBC, the wrong credentials are passed.
Even if you create a local windows account (LWA) on the machine (SE) that has SQL Express installed (SE\LWA), the credentials that will be passed from your client machine (CM) will be CM\LWA.
As mentioned here, you might need to disable the loopback
Loopback check can be removed by adding a registry entry as follows:
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck” Set this value to 1
If you using windows authentication make sure that password of the user hasn't expired. An expired password can explain this error. This was the problem in my case.
Same Error with Connection String in Visual Studio dev environment
Our development database server was recently given a self-signed certificate so it automatically became untrusted. This resulted in the login error cited above. I added TrustServerCertificate=True to my connection string and it works now.
"Server=TheServerAddress; Database=TheDataBase; User Id=TheUsername; Password=ThePassword; TrustServerCertificate=True"
NOTE: This certificate configuration is not recommended for production environments.
In my case the Aliases within SQL Native Client 11.0 Configuration were pointing to invalid server/IP. Once updated it worked correctly.
To check:
1. Start "SQL Server Configuration Manager"
2. Navigate to "SQL Native Client 11.0 Configuration" and then "Aliases"
3. Ensure "Alias Name" and "Server" match correctly for TCP/IP
Following worked for me to get access from another machine to SQL Server using Windows Authentication. This approach may be useful only in development/test environment. E.g. you need to update password manually once you change it on your working machine.
On machine with SQL Server go to Control Panel and add new Windows User with same username and password as is on your working machine. Then create SQL Server login for this user:
CREATE LOGIN [SQLSERVERHOST\myuser] FROM WINDOWS;
Now you can use this login for Windows Authentication.
If you receive error 'The login is from an untrusted domain', this may mean that you changed password on your working machine and now need to update password on SQL Server machine.
Just adding my suggestion for a resolution, I had a copy of a VM server for developing and testing, I created the database on that with 'sa' having ownership on the db.
I then restored the database onto the live VM server but I was getting the same error mentioned even though the data was still returning correctly. I looked up the 'sa' user mappings and could see it wasn't mapped to the database when I tried to apply the mapping I got a another error "Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405". so I ran this instead
ALTER AUTHORIZATION ON DATABASE::dbname TO sa
I rechecked the user mappings and it was now assigned to my db and it fixed a lot of access issues for me.
Joining a WORKGROUP then rejoining the domain fixed this issue for me.
I got this error while using Virtual Box VM's. The issue started to happen when I moved the VM files to a new drive location or computer.
Hope this helps the VM folks.
We now use a privileged account management solution that changes our passwords regularly. I ended up receiving this error after my password was changed. Closing and re-opening SSMS with the new password resolved my issue.
I started to get this error when i tried to login to SSMS using 'windows Authentication'. This started to happen after i renamed the Windows SQL server. I tried everything to resolve this error and in my particular case changing the machine names in the 'hosts' file to reflect the name SQL server name change resolved the issue. C:\Windows\System32\Drivers\etc\hosts
I had this problem because we where using a DNS name from an old server, ponting to a new server. Using the newserver\inst1 address, worked. both newserver\inst1 and oldserver\inst1 pointed to the same IP.
Yet another thing to check:We had our nightly QA restore job stop working all of a sudden after another developer remoted into the QA server and tried to start the restore job during the middle of the day, which subsequently failed with the "untrusted domain" message. Somehow the server pointed to be the job's maintenance plan was (changed?) using the ip address, instead of the local machine's name. Upon replacing with the machine name the issue was resolved.
TLDR: Changing the DNS server to the loop back address worked for me.
I am working in VirtualBox and had setup two Windows Server 2016 instances. Server A is configure as a Domain Controller and Server B as an SQL Server. After adding Server B to the domain I cold not connect to with Management Studio from Server A. I was getting the "The login is from an untrusted domain and cannot be used with Windows authentication".
My initial configuration had the server getting its IP from the VirtualBox DHCP server.
I changed this to use static IP and entered the 127.0.0.1 address in the Primary DNS and this worked for me.
Hope this helps someone passing by.
I enabled Trust Server Certificate in the Connection Properties and it worked for me
You might find out that you have more than one connection string, and you forgot to change the other one to Integrated Security to false. It happened to me. This answer might help someone.
I was focusing on the web config and the access rights, after a long hustle i remembered that I have another connection string in one of my classes for the emails, I had to change the connection string on the class to use the web config one.
i removed Integrated Security=true and Trusted_Connection=True both of them , worked for me..
In .net Core also you may get this error if Trusted_Connection=True;
Is set. Sample setting in appsettings.json
ConnectionStrings": {
"DefaultConnection": "Server=serverName; Database=DbName; uid=userId; pwd=password; MultipleActiveResultSets=true"
},
Sometime SSMS hang and close all of sudden ,then you get below error when you reconnect to SSMS
i) The Login is From an Untrusted Domain and Cannot be Used with Windows Authentication
OR
ii) The target principal name is incorrect .Cannot generate SSPI context.
In both cases RESTART YOUR MACHINE.
I also had a similar error but then I realised I just had changed the password for my system which caused this error.
To resolve it , I simply logged out of the current session and logged in again and this time
Please Use This Connection URL It's Work Fine
"Data Source=Your IP Address;Initial Catalog = DatabaseName;User ID =sa;Password =your PassWord;TrustServerCertificate=True"
Example : "Data Source=192.168.150.122;Initial Catalog=StudentDb;User ID=sa; PassWord=123;TrustServerCertificate=True"
If you have two servers on the same domain (eg. APP and DB), you can also use Windows Authentication between the app and MSSQL by setting up local users on both machines that match (same username and password). If you don't have the passwords matched up, it can throw this error.
Following was working for me. hope this helps you
<add name="getconn" connectionString="Data Source=servername;Initial Catalog=DBName;Persist Security Info=True;User ID=sa;Password=***" />