[sql-server] Trouble Connecting to sql server Login failed. "The login is from an untrusted domain and cannot be used with Windows authentication"

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.

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.

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.

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.

In order to use Windows Authentication one of two things needs to be true:

1. You are executing from the same machine as the database server.
2. 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:

1. Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
2. 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.

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.

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.

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.

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 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=***" />

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.

Getting rid of Integrated Security=true worked for me.

I was facing the issue while connecting to SQL Always On Listener. Disabling the loop back check resolved the issue.

1. Edit the registry using regedit. (Start –> Run > Regedit )

2. Navigate to: HKLM\System\CurrentControlSet\Control\LSA

3. Add a DWORD value called “DisableLoopbackCheck”

4. Set this value to 1

https://blog.sqlauthority.com/2017/04/18/sql-server-login-failed-login-untrusted-domain-cannot-used-windows-authentication/

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.

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.

In .net Core also you may get this error if Trusted_Connection=True; Is set. Sample setting in appsettings.jason

ConnectionStrings": {
"DefaultConnection": "Server=serverName; Database=DbName; uid=userId; pwd=password; MultipleActiveResultSets=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.

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

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

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.

This error message can also occur if the account you are using to access the SQL server is locked out by the domain.

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.

I enabled Trust Server Certificate in the Connection Properties and it worked for me