I am trying to configure SQL Server 2014 so that I can connect to it remotely using SSL. A valid, wildcard cert is installed on the server, and the cert's domain name (example.com) matches the server's FQDN (test.windows-server-test.example.com).
The problem is that in SQL Server Configuration Manager, the certificate is not listed, so I cannot select it.
That is, I am stuck on step 2.e.2 from this MS tutorial.
After communication in comments I can suppose that your main problem is the CN part of the certificate which you use. To have successful TLS communication for IIS Server one have no such strong restrictions like SQL Server has.
Microsoft require (see here) that The name of the certificate must be the fully qualified domain name (FQDN) of the computer. It means that the Subject part of the certificate looks like CN = test.widows-server-test.example.com, where test.widows-server-test.example.com is the FQDN of your computer. It's not enough that you use for example CN = *.example.com and Subject Alternative Name, which contains DNS Name=*.example.com and DNS Name=test.widows-server-test.example.com, DNS Name=test1.widows-server-test.example.com, DNS Name=test.widows-server-test2.example.com and so on. Such certificate will be OK for TLS, but SQL Server will discard it. See the article, which describes close problems.
I recommend you to create self-signed certificate with CN equal to FQDN of the SQL Server and to verify that the certificate will be seen by SQL Server Configuration Manager.
UPDATED: I analysed the problem a little more with respect of Process Monitor and found out that two values in Registry are important for SQL Server Configuration Manager: the values Hostname and Domain under the key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
If I change Domain and Hostname to the values which corresponds CN of the certificate then the certificate will be already displayed in the SQL Server Configuration Manager. It could be not all problems, but it shows that SQL Server required much more as a web server (IIS for example).
UPDATED 2: I examined the problem once more in details and I think I did found the way how one can configure common SSL certificate which you already have (for example free SSL certificated from Let's Encrypt, StartSSL or some other).
It's important to distinguished what do SQL Server Configuration Manager from the configuration required by SQL Server. The Certificate tab of the properties of the Configuration Manager have more hard restrictions as SQL Server. I describe above only the restrictions of SQL Server Configuration Manager, but one can make configuration directly in the Registry to use more common SSL/TLS Certificate by SQL Server. I describe below how one can do this.
What one need to do one can in the Registry under the key like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12.SQL2014\MSSQLServer\SuperSocketNetLib, where the part MSSQL12.SQL2014 can be a little different in your case. The SQL Server Configuration Manager help us to set two values in the registry: ForceEncryption and Certificate:
The Certificate value is SHA1 hash which can be found by examining the properties of the certificate:
or extended properties of the certificate, which you see by usage certutil.exe -store My:
One need just copy the "Cert Hash(sha1)" value, remove all spaces and to place as the value of Certificate value in the Registry. After making the settings and restarting SQL Server windows service one will see in file ERRORLOG in C:\Program Files\Microsoft SQL Server\...\MSSQL\Log directory the line like
2016-04-25 21:44:25.89 Server The certificate [Cert Hash(sha1)
"C261A7C38759A5AD96AC258B62A308A26DB525AA"] was successfully loaded
for encryption.
I want to add this for future folks that may stumble on a similar issue I encountered with SQL 2016 SP2 and failover cluster. The certificate thumbprint added to the registry had to be all upper case.
Hope this helps the next guy.
Once I followed steps in Updated 2 section of accepted answer, I can't start the SQL Server service, got those errors in Event Viewer:
Unable to load user-specified certificate [Cert Hash(sha1) "thumbprint of certificate"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property.
TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Cannot find object or property.
got error in SQL Server error log:
The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d. Check certificates to make sure they are valid.
googled it and found out a solution:
Make sure the windows account running SQL Server service (NT Service\MSSQLServer in my case) has full permissions to the following folders/register entry:
C:\Program Files\Microsoft SQL Server[Your Sql Server Instance]\MSSQL\
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
HKLM\System\CurrentControlSet\Services\WinSock2\Parameters
I checked No.1 NT Service\MSSQLSERVER has already had the permission.
I checked No.2, NT Service\MSSQLSERVER has no permission and I added the permission. It popped up an error saying one of files in that folder was denied the operation, but I just ignored it (nothing else I can do)
I didn't check No.3 and tried starting SQL Server, it worked!!
I faced similar issue in SSRS, wherein certificate issued by microsoft active directory CA was not visible in the dropdown in SSRS. After lot of searches, trial and error I could fix it by following this link.
https://learn.microsoft.com/en-us/archive/blogs/sqlserverfaq/can-tls-certificate-be-used-for-sql-server-encryption-on-the-wire
Brief of it is as below:
The Subject property of the certificate must indicate that the common name (CN) is the same as the host name or fully qualified domain name (FQDN) of the server computer.
So in our case we suggested to request the Certificate Authority to change the Subject name to ABC-SQLServer.abc.local (FQDN of SQL Server) instead of abc-corp.abc.com
Once this change was done, we loaded certificate again in MMC and now we could see the certificate loaded in SQL Server Configuration Manager!
Hope it helps someone facing same issue!
I was still having problems even after following the above. This is my fix:
in the certificates mmc right click the certificate All tasks->Manage Pricate Keys. Give the service account full control. In my case I am using NT Service\MSSQL$
SQL Server 2019
I found that the certificate thumbprint had to be entered into the certificate registry key in lower case for Configuration Manager to see it.
SQL Server will read the registry value and use it whether the registry key is in upper or lower case.
But configuration Manager will only display it if it is in lower case
I logged on to the server with SQL Server domain account( had to add the account to local admins temporarily) and imported the certificate in personal folder of the SQL Server service account. rebooted the server, and then SQL Server could see the certificate. Hope it helps someone.
An additional failure mode is key length - SQL requires a minimum keylength of 2048. With DH channel disabled.
I have also run into an issue copying out of the MMC as detailed in the article here. Using the certutil and copying that into the registry value worked perfectly.
My problem was that the Certificate Store was for WebHosting, but to see the certificate in SSRS it must be Personal.
USE UPPER CASE for Certificate in Registry editor LOL
Still not shown in config manager but TLS is working for SQL connections.
Related
I installed SQL2019 and SQL Server Management Studio.
SQL Server with name "TESTINSTANCE" is running.
When I press "Test Connection" then I get this error:
[08S01] The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target". ClientConnectionId:9d6e6b90-bd20-4364-b0e4-bfbdd6bc57c8 unable to find valid certification path to requested target.
It seems like my solution would be tab SSH/SSL -> Use SSL, but I don't know where should I get certificate files. Maybe it's something else, I don't know.
UPDATE:
All my first attempts was without "Use SSL", it doesn't work either.
Jdbc driver is installed by Rider by default.
Server=LEKRET\TESTINSTANCE don't work (Incorrect driver and/or database URL specified).
UPDATE 2:
Well, I finally found where I can enable Trust Server Certificate, in Advanced Options. Not ideal, but everything is on local machine so it should be fine.
Password and login didn't work, but I finally managed to create login with windows auth in SSMS.
After 8 hours it's finally working.
I recently created a self-signed certificate and turned encryption on in SQL Server 2014:
The problem is that now the SQL Server service won't start:
This article from 2010 identifies the problem as a permissions issue: The SQL Server service does not have the necessary permission to read the SSL cert's private key.
The problem is that I am stuck on step 4 of the solution proposed in the article:
There is no group or user name matching the proposed format when I bring up the window shown in the article.
Is there another way I can determine the account that SQL Server service runs under, so that I can give it permissions to read the SSL cert?
An entirely different solution is welcome too.
If you specify the certificate, which should be used for TLS by SQL Server, then the SQL Server windows service have to read the certificate and the private key (the file from the folder %ProgramData%\Microsoft\Crypto\RSA\MachineKeys), which corresponds the certificate. The problem is: the SQL Server Configuration Manager in not comfortable and it makes not all the required work.
Thus first of all one should localize the Account used by SQL Server. One should start services.msc, find the account of SQL Server service. It's typically a build-in account like Local System, Network Service a local or domain account like .\SQLServer, DOMAIN\SQLServerAccount or an service account like NT Service\NT Service\MSSQL$SQL2012 on the picture below:
To grant permission on the private key to the account one can use Certificate Snap-In of mmc. One can start mmc.exe, choose "Add/Remove Snap-in" in the "File" menu, choose "Certificates" Snap-in and to choose "Computer account" of the Local computer. Then one should select the SSL certificate of Personal store and then use context menu "Manage Private Keys...".
and to add account like NT Service\NT Service\MSSQL$SQL2012, found above, and to set "Read" permission to the account on the private key:
If you would like to establish connection to the SQL server inside of the domain (both the client and the server have to belong to the same Active Directory or to the directories connected via the trust) then one should to create SPNs for the SQL server. If I correctly understand your requirements, you want to allow remove connection to SQL Server over HTTPS. One have to active mixed security to be able to connect to the server via SQL Server Authentication:
After creating SQL Login, making all above changed and restarting SQL Server service one will be able to establish TLS (encrypted) connection to the SQL server. In case of attempting to connect via Windows Account without creating SPN previously one get the error:
A connection was successfully established with the server, but then an
error occurred during the login process. (provider: SSL Provider,
error: 0 - The target principal name is incorrect.) (Microsoft SQL
Server, Error: -2146893022)
The target principal name is incorrect
If one forget to change Windows Authentication to Mixed authentication () then one will get the error like
Login failed for user 'OlegKi'. (Microsoft SQL Server, Error: 18456)
If all above steps done one can establish TLS connection using SQL Management Studio for example, but one still have to choose some options:
One should check "Encrypt connection"
and to set additional connection property TrustServerCertificate=true
Typically one use Encrypt=true;TrustServerCertificate=true; as the part of connection string in the application which establish the connection to SQL server. We set Encrypt=true property by the checkbox "Encrypt connection" describe above. More detailed about the meaning of the properties and different combinations of the options can be read in "Enabling Encryption" section of the MSDN article.
If one do all the above steps and check "Encrypt connection" without setting TrustServerCertificate=true property then one will get the error:
A connection was successfully established with the server, but then an
error occurred during the login process. (provider: SSL Provider,
error: 0 - The target principal name is incorrect.) (Microsoft SQL
Server, Error: -2146893022)
The target principal name is incorrect
which I already described above in a little another situation (connection with Windows account).
I described all above steps because configuration of TLS connection to the server is really not so easy and one can get strange errors, which direct description gives no direct tips how to fix the problem.
One other note: If you are entering the certificate thumbprint into the registry manually by copying and pasting from the certificate manager, you must remove the leading character. It is an invisible unicode character, but it will cause the SQL Server service to be unable to start if it is present. This is in addition to making it ALL CAPS, and removing all spaces.
I ran into this issue as well. What i was doing was:
Importing the certificate from the sql server protocol properties dialog, using the 'import' button. I imported the public key, then another open dialog opened to import the private keys. I then set the private key permission to the sql server service.
When importing a key pair directly, such as a .pfx bundle, the application crashed.
All permissions to MachineKeys were granted as well for the sql serive, but I could not find through process monitor any access denied for that path.
In order to solve my issue, i imported the pfx directly from the explorer. I first removed the key pair from the store, then I ran through the wizard to import the pfx in the local machine store, personal folder. I checked the permissions on the private key, they were still set for the sql service. I checked the protocol properties, the certificate was already selected. Only then the server started.
I am struggling to get a SQL Server connection from machine A to machine B which is running the SQL Server.
I have Googled extensively and all the things I have found have not worked. Nor do they lead you step by step through the process of solving this.
We are not using Kerberos, but NTLM where configured.
The machines involved are (xx is used to obscure some of the machine name for security purposes):
xxPRODSVR001 - Windows Server 2012 Domain Controller
xxDEVSVR003 - Windows Server 2012 (This machine is generating the error)
xxDEVSVR002 - Windows Server 2012 (This machine is running SQL Server 2012)
The following SPN's are registered on the DC (xxPRODSVR001). I have obscured the domain with yyy for security purposes:
Registered ServicePrincipalNames for CN=xxDEVSVR002,CN=Computers,DC=yyy,DC=local:
MSSQLSvc/xxDEVSVR002.yyy.local:49298
MSSQLSvc/xxDEVSVR002.yyy.local:TFS
RestrictedKrbHost/xxDEVSVR002
RestrictedKrbHost/xxDEVSVR002.yyy.local
Hyper-V Replica Service/xxDEVSVR002
Hyper-V Replica Service/xxDEVSVR002.yyy.local
Microsoft Virtual System Migration Service/xxDEVSVR002
Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local
Microsoft Virtual Console Service/xxDEVSVR002
Microsoft Virtual Console Service/xxDEVSVR002.yyy.local
SMTPSVC/xxDEVSVR002
SMTPSVC/xxDEVSVR002.yyy.local
WSMAN/xxDEVSVR002
WSMAN/xxDEVSVR002.yyy.local
Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local
TERMSRV/xxDEVSVR002
TERMSRV/xxDEVSVR002.yyy.local
HOST/xxDEVSVR002
HOST/xxDEVSVR002.yyy.local
Registered ServicePrincipalNames for CN=xxDEVSVR003,CN=Computers,DC=yyy,DC=local:
MSSQLSvc/xxDEVSVR003.yyy.local:1433
MSSQLSvc/xxDEVSVR003.yyy.local
Hyper-V Replica Service/xxDEVSVR003
Hyper-V Replica Service/xxDEVSVR003.yyy.local
Microsoft Virtual System Migration Service/xxDEVSVR003
Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local
Microsoft Virtual Console Service/xxDEVSVR003
Microsoft Virtual Console Service/xxDEVSVR003.yyy.local
WSMAN/xxDEVSVR003
WSMAN/xxDEVSVR003.yyy.local
TERMSRV/xxDEVSVR003
TERMSRV/xxDEVSVR003.yyy.local
RestrictedKrbHost/xxDEVSVR003
HOST/xxDEVSVR003
RestrictedKrbHost/xxDEVSVR003.yyy.local
HOST/xxDEVSVR003.yyy.local
Now if only the SQL Server error message was more descriptive and told me what principal name it was trying to connect to I might be able to diagnose this.
So can anyone step me through how to solve this one or can you see anything in what I have provided that is wrong?
I would be happy to generate more debug info, just tell me what you need.
I had this problem with an ASP.NET MVC app I was working on.
I realized I had recently changed my password, and I was able to fix it by logging out and logging back in again.
The SSPI context error definitely indicates authentication is being attempted using Kerberos.
Since Kerberos authentication SQL Server's Windows Authentication relies on Active Directory, which requires a trusted relationship between your computer and your network domain controller, you should start by validating that relationship.
You can quickly check that relationship, thru the following Powershell command Test-ComputerSecureChannel.
Test-ComputerSecureChannel -Verbose
If it returns False, you must repair your computer Active Directory secure channel, since without it no domain credencials validation is possible outside your computer.
You can repair your Computer Secure Channel, thru the following Powershell command:
Test-ComputerSecureChannel -Repair -Verbose
If the above doesn't work (because your domain credentials don't work because the machine isn't trusted) you can use NETDOM RESET instead from an elevated cmd.exe (not PowerShell) prompt:
NETDOM RESET %COMPUTERNAME% /UserO:domainAdminUserName /Password0:* /SecurePasswordPrompt
(Yes, the command-line arguments really do have an O (Capital-"Oh", not zero 0). The /Password0:* /SecurePasswordPrompt option will use a credential popup instead of having you put your password directly in the command-line, which you must never do).
Check the security event logs, if you are using kerberos you should see logon attempts with authentication package: Kerberos.
The NTLM authentication may be failing and so a kerberos authentication attempt is being made. You might also see an NTLM logon attempt failure in your security event log?
You can turn on kerberos event logging in dev to try to debug why the kerberos is failing, although it is very verbose.
Microsoft's Kerberos Configuration Manager for SQL Server may help you quickly diagnose and fix this issue.
Here is a good story to read: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/
I was getting the same error when trying through windows authentication. Sounds ludicrous but just in case it helps someone else: it was because my domain account got locked somehow while I was still logged in (!). Unlocking the account fixed it.
Try setting Integrated Security=true to remove this param from the connection string.
IMPORTANT: As user #Auspex commented,
Removing Integrated Security will prevent this error, because the error occurs when trying to login with your Windows credentials. Unfortunately, most of the time, you want to be able to login with your Windows credentials
I was logging into Windows 10 with a PIN instead of a password. I logged out and logged back in with my password instead and was able to get in to SQL Server via Management Studio.
Just to add another potential solution to this most ambiguous of errors The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) :
Verify that the IP that is resolved when pinging the SQL Server is the same as the one in the Configuration Manager. To check, open SQL Server Configuration Manager and then go to SQL Server Network Configuration > Protocols for MSSQLServer > TCP/IP.
Make sure TCP/IP is enabled and in the IP Addresses tab, make sure that the IP that the server resolves to when pinging is the same one here. That fixed this error for me.
I just ran into this and fixed it by doing 2 things:
Granting read/write servicePrincipalName permissions to the service account using ADSI Edit, as described in https://support.microsoft.com/en-us/kb/811889
Removing the SPNs that previously existed on the SQL Server computer account (as opposed to the service account) using
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
where 1234 was the port number used by the instance (mine was not a default instance).
This is usually due to missing, incorrect or duplicated Service Principle Names (SPNs)
Steps to resolve:
Confirm what AD account SQL Server is using
Run the following command in Powershell or CMD in administrator mode (service account should not contain the domain)
setspn -L <ServiceAccountName> | Select-String <ServerName> | select line
Make sure the returned output contains an SPN which is fully qualified, no fully qualified, with a port and without a port.
Expected Output:
Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com:
MSSQLSvc/<ServerName>.<domain>.com:1433
MSSQLSvc/<ServerName>:1433
MSSQLSvc/<ServerName>.<domain>.com
MSSQLSvc/<ServerName>
If you don't see all of the above, run the following command in PowerShell or CMD in admin mode (make sure to change the port if you don't use default 1433)
SETSPN -S MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>
Once above is complete it normally takes a few minutes for DNS propagation
Also, if you get a message about duplicate SPNs found, you may want to delete them and recreate them
The issue seems to be a windows credentials issue. I was getting the same error on my work laptop with a VPN. I am supposedly logged in as my Domain/Username, which is what I use successfully when connecting directly but as soon as I move to a VPN with another connection I receive this error. I thought it was a DNS issue as I could ping the server but it turns out I needed to run SMSS explicitly as my user from Command prompt.
e.g
runas /netonly /user:YourDoman\YourUsername "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"
Login to both your SQL Box and your client and type:
ipconfig /flushdns
nbtstat -R
If that doesn't work, renew your DHCP on your client machine... This work for 2 PCs in our office.
Check your clock matches between the client and server.
When I had this error intermittently, none of the above answers worked, then we found the time had drifted on some of our servers, once they were synced again the error went away. Search for w32tm or NTP to see how to automatically sync the time on Windows.
In my case, restarting SQL Server 2014 (on my development server) fixed the issue.
I had this problem when accessing the web application. It might be due to i have changed a windows password recently.
This issue got resolved when i have updated the password for the app pool where i have hosted the web application.
I was testing out IPv6 on a cluster of PC's in an isolated network and ran into this issue when I reverted back yo IPv4. I had been play in the active directory, DNS and DHCP so have no idea what I prodded to break the Kerberos setup.
I retested the connection outside of my software with this useful tip to connect remote connectivity I found.
https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/
then after a brief search found this on the Microsoft website
https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message.
run the tool on the SQL server see if there are any issue
if the status says error then hit the fix button that appears.
This resolved the problem for me.
In my situation I was trying to use Integrated Security to connect from a PC to SQL Server on another PC on a network without a domain. On both PCs, I was signing in to Windows with the same Microsoft account. I switched to a local account on both PCs and SQL Server now connects successfully.
I had the same issue, but locking, and unlocking the machine worked for me. Sometimes, firewall issues will give errors.
I am not sure it will work for you or not, just sharing my experience.
This Microsoft Tool is like Magic. Run it, connect it to the SQL server, and click Fix
The old version linked here worked on SQL server 2017.
Kerberos Configuration Manager for SQL Server
https://www.microsoft.com/en-us/download/details.aspx?id=39046
Since I landed here when looking for a solution to my own problem, I'll share my solution here, in case others land here as well.
I was connecting fine to SQL Server until my machine was moved to another office on another domain. Then, after the switch, I was getting this error regarding the target principal name. What fixed it was connecting using a fully qualified name such as: server.domain.com. And actually, once I connected to the first server that way, I could connect to other servers using just the server name (without the full qualification), but your mileage may vary.
In my Case since I was working in my development environment, someone had shut down the Domain Controller and Windows Credentials couldn't be authenticated. After turning on the Domain Controller, the error disappeared and everything worked just fine.
In case anyone is wondering, I untangled the MS terminology:
Target = (active directory) target
Active directory target = target server running the domain controller
Domain controller = server that verifies your login information
Principal name = your windows username
SSPI = security support provider interface
Security support provider interface = software interface that manages "authenticated
communications" and allows SSPs like TLS to allow SSL, among others
SSP = security support provider (SSPI implementation)
TLS/SSL = you should already know this
= Can't verify your password.
I ran into this today and wanted to share my fix, since this one is simply overlooked and easy to fix.
We manage our own rDNS and recently redid our server naming scheme. As part of that, we should have updated our rDNS and forgot to do this.
A ping turned up the correct hostname, but a ping -a returned the wrong hostname.
Easy fix: change the rDNS, do an ipconfig /flushdns, wait 30 seconds (just something I do), do another ping -a , see it resolving the correct hostname, connect ... profit.
I ran into a variant of this issue, here were the characteristics:
User was able to successfully connect to a named instance, for example, connections to Server\Instance were successful
User was unable to connect to the default instance, for example, connections to Server failed with the OP's screenshot regarding SSPI
User was unable to connect default instance with fully qualified name, for example, connections to Server.domain.com failed (timeout)
User was unable to connect IP address without named instance, for example, connections to 192.168.1.134 failed
Other users not on the domain (for example, users who VPN to the network) but using domain credentials were able to successfully connect to the default instance and IP address
So after many headaches of trying to figure out why this single user couldn't connect, here are the steps we took to fix the situation:
Take a look at the server in the SPN list using
setspn -l Server
a. In our case, it said Server.domain.com
Add an entry to the hosts file located in C:\Windows\System32\drivers\etc\hosts (run Notepad as Administrator to alter this file). The entry we added was
Server.domain.com Server
After this, we were able to successfully connect via SSMS to the default instance.
I ran into a new one for this: SQL 2012 hosted on Server 2012.
Was tasked to create a cluster for SQL AlwaysOn.
Cluster was created everyone got the SSPI message.
To fix the problems ran following command:
setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService
DomainNamerunningSQLService == the domain account I set for SQL
I needed a Domain Administrator to run the command. Only one server in the cluster had issues.
Then restarted SQL. To my surprise I was able to connect.
I was trying to connect to a VM running SQL Server 2015 from my laptop in a Visual Studio 2015 Console App. I run my app the night before and it is fine. In the morning I try to debug the app and I get this error. I tried ipconfig/flush and release + renew and a a bunch of other garbage, but in the end...
Restart your VM and restart the client. That fixed it for me. I should have known, restart works every time.
I had this problem on my sql server. I setspn -D mssqlsvc\Hostname.domainname Hostname then stoped and started my SQL server service.
I am thinking that just stopping and starting my sql service would have done it.
I have tried all the solutions here and none of them have worked yet. A workaround that is working is to Click Connect, enter the server name, select Options, Connection Properties tab. Set the "Network protocol" to "Named Pipes". This allows users to remote connect using their network credentials. I'll post an update when I get a fix.
In my case, the problem was setting up DNS on the wifi. I removed the settings, and left them empty, and worked.
Make sure that "Named Pipes" are enabled from "SQL Server Configuration Manager". This worked for me.
Open "SQL Server Configuration Manager".
Expand "SQL Server Network Configuration", from the list on the left.
Select "Protocols for [Your Instance Name]".
Right click on "Named Pipes", from the list on the right.
Select "Enable"
Restart your Instance service.
Another niche to this issue caused by network connections. I connect via windows VPN client and this issue popped up when I switched from Wifi to a wired connection. The fix for my situation was to manually adjust the adapter metric.
In powershell use Get-NetIPInterface to see all of the metric values. The lower numbers are lower cost and so they are preferred by windows. I switched the ethernet and VPN and the credentials got where they needed to be for SSMS to be happy.
To configure the Automatic Metric feature:
In Control Panel, double-click Network Connections.
Right-click a network interface, and then select Properties.
Click Internet Protocol (TCP/IP), and then select Properties.
On the General tab, select Advanced.
To specify a metric, on the IP Settings tab, select to clear the Automatic metric check box, and then enter the metric that you want in the Interface Metric field.
Source:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes
I have been unable to solve this in a satisfactory manner. If I log in from a client as a local Windows account, Windows authentication works without a glitch. If I however attempt to log in from a Microsoft account (which is preferable for me because of the synchronization features), I get the "incorrect principal" message. No record of the failed login appears in the MS-SQL logs, implying that the failure occurs very early.
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=***" />
Background Information:
I have a single Window VPS at example.com.
I have it running IIS and SQL Server.
I have a certificate for example.com that works fine with IIS.
I want to use the same certificate for SQL Server to allow encrypted connections with clients.
SQL Server Configuration Manager does not present the certificate in the drop down.
I believe the problem is that SQL Server does not think the certificate is valid, because what SQL Server thinks the server name is does not match the certificate (example.com).
How do I check what SQL Server thinks the server name is? If it is wrong how would I change it?
Okay I found out the issue.
The hostname on my machine was wrong. It wasn't "example.com", but some name randomly generated by windows. You can set this in the computer's properties window.
The certificate was not registered to be used on port 1433. I had to use netsh to enable the certificate to be used on port 1433. Instructions here: http://msdn.microsoft.com/en-us/library/ms186362(v=SQL.100).aspx
Those two steps where complete I got the certificate to show up in SQL Server Configuration Manager, but I still had a problem went I attempt to run SQL Server. It would not start with a message from the logs saying it could not find or read the SSL Certificate.
The last step was making sure the account running SQL Server had permission to read the certificate. I went into the certificate snap-in and then went to properties under the certificate, then on the Security tab I gave the Network Services account read permission on the certificate. (NOTE: I did not find any tutorials online reference this step. It was just some dumb luck that I found this.)
After those steps where complete the SQL Server Service start up with out any problem.