i have active directory, both sql server db01 and db02 are joined in domain and setup default all.
i'm trying to connect another sql server instance db02 from db01 sql server
file->connect
Server Type: Database Engine
Server Name (i tried IP address or FQDN but it's still not working)
Authentication: Windows Authentication
Domain\Administrator
When i click connect button it says
enter image description here
i also tried enabling the sa account and setting password, can't also connect
i tried firewall off on both db01 and 02, still the same issue.
all services for sql is running, and network tcp and pipename are enabled.
remote connection is set to enable/allow
did i miss anything?
I think the error message tells you correctly that the problem is around authentication.
Either you are using a non-Windows application to connect to the the SQL server instances OR you are logged with your normal account BUT you are trying to authenticate as Domain\Administrator. Windows authentication will mostly not let you do that.
A problem with some non-Windows tools is that they let you try to connect using Windows Authentication and typing in a username, but it will never work. Instead, to use windows authentication you have to login to Windows as Domain\Administrator OR run your Application as Domain\Administrator, using e.g. right-click 'Run as other user'
To connect from a non-Windows platform using windows authentication depends entirely on your application and driver having correctly implemented it.
Related
The authentication mode is "Mixed" for my SQL Server 2016.
I'm using SSMS to run cross-server queries.
I've checked the user account & have ensured that the account has proper authority. I can use a different account and run cross-server queries as expected. The account has proper authority to the databases in question and it has authority to them. I've tried everything I've seen on the internet searches I've done and no luck. The account can login using SSMS.
My linked server properties are:
The account's login properties are:
Has anyone else seen this & have a resolution?
** EDIT: rebooting the target server fixed the issue
When creating a linked server you choose the authentication mechanism by which the remote connection will be made. If you select the fourth option (pictured), the remote login must be a Sql Server authenticated login. It cannot be a windows login.
The only way to connect through a linked server using windows authentication is to forward the credentials of the login on the local server. There is no option to specify a windows username and password.
Indeed, there is no way, ever, to specify a password when connecting to a Sql Server with windows credentials, since the whole point of windows credentials is that you're already authenticated. That happened when you logged in to windows in the morning*
You can only (and must always) specify a password if you are using Sql Server authentication.
What seems to be going on in your case is that the linked server may have been created with the wrong security options. This is just easier to explain with an image:
* More precisely, a connection will be made using the account that the client is running under. If you start SSMS using a "runas /user ..." command, then the windows credentials used to connect to servers will be the credentials specified in runas
I have installed SQL Server 2012 Express edition on a pc which is on a workgroup running Windows 10. I have also created an user for access to the database through the VS2013 application.
When trying to connect to the server from the client machine, I am getting a message saying login failed and it is from an untrusted domain. The client is also on the same workgroup. However, after the SQL Express was installed on the "server" machine, the name of that pc was changed. I can connect to the database from the server using SSMS using the new computer name (in the instance). I have set remote connection parameters and also configured firewall rules. Yet I am unable to access the server from the client machine.
I also want to ensure that the database is totally secured against access or intrusion. Anyone having access to the server machine can view/edit the database using Windows Authentication. How best to safeguard against it?
Any tips would be appreciated.
CL
try to make a new user in server machin using SSMS and be sure that you are adding the new user to the Login Part of Security in SSMS . For this you need to Login to SSMS as administrator ...
I need to connect to a SQL Server 2008 instance in another Windows domain to manage it. We only use Windows Authentication.
In Windows XP, I could use the "Manage Network Passwords" feature to store on my local machine my username and password for the remote machine. Doing so would cause SQL Server Management Studio to use those credentials, instead of my local credentials, when connecting to that server. This worked great, and prevented my having to enter a username or password every time I connected with SSMS.
But, Holy Cow, after upgrading to Windows 7, I can no longer do this. Adding my remote domain credentials in Credential Manager fails to produce the desired behavior. SMSS 2008 R2 ignores the stored credentials, and instead, always sends my local credentials, causing the login to fail every time. There's not even a way, within SMSS, to enter alternate credentials, so the upshot is that I simply cannot access the remote server!
The login fails with the following message:
Login failed. The login is from an
untrusted domain and cannot be used
with Windows authentication.
(Microsoft SQL Server, Error: 18452)
How can I get SMSS on Windows 7 to work the same way it did on Windows XP?
It looks like there is a bug in the Windows 7 Credential Manager that causes this behavior. After lots of Internet research, I found some ugly workarounds, but also found a great one:
In Credential Manager, add an entry for the remote server, but instead of adding just the server name, like database.contoso.com, add the server name with the SQL Server port, like so:
database.contoso.com:1433
This results in the desired behavior, with no pain!
Source: http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/c05a90e4-cb16-46f6-9072-37083c65696d/
Also remember, of course, that you need to prefix the remote username in Credential Manager with the remote domain name, like so:
database\administrator
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan
Ever since moving to Vista some time ago on my development machine, connecting to SQL Servers in our DMZ active directory domain from client tools like SSMS has not worked like it used to. In XP, as long as I had authenticated in some way on the server (for example directing Explorer to \server.dmzdomain\c$ and entering valid creds into the login prompt), SSMS would use those cached credentials to connect.
However since switching to Vista, when trying to connect SSMS to a server in the DMZ domain I get the message Login failed for user ''. The user is not associated with a trusted SQL Server connection. If I change the connection options to use Named Pipes instead of the default TCP/IP, my cached credentials are sent and everything works fine. This is the case whether Windows Firewall is off or on, and connections to servers in our internal domain (the same domain my dev PC is in) work fine over TCP/IP or named pipes.
I don't mind too much using named pipes for these connections as a workaround, but it seems like TCP/IP is the recommended connection method and I don't like not understanding why it's not working as I'd expect. Any ideas?
"Login Failed for user ' ', the user is not associated with a trusted SQL Server connection".
In this scenario, client may make tcp connetion, plus, running under local admin or non-admin machine account, no matter SPN is registered or not, the client credential is obviously not recognized by SQL Server.
The workaround here is:
Create the same account as the one on the client machine with same password on the target SQL Server machine, and grant appropriate permission to the account.
Let's explain in more detail:
When you create the same NT account (let's call it usr1) on both
workstations, you essentially connect and impersonate the local account of
the connecting station. I.e when you connect from station1 to station2,
you're being authenticated via the station2's account. So, if you set the
startup account for SQL Server (let's assume it's running on station2) to be
station2's usr1, when you connect to SQL from station1 with station1's usr1
login, SQL will authenticate you as station2's usr1.
Now, within SQL, you can definitely access station1's resources. Though, how
much access will depend on station1's usr1 permission.
So far, SQL only deal with an user who is part of the sysadmin role within
SQL Server. To allow other users (non-sysamdin) access to network resources,
you will have to set the proxy account. Take a look at the article for
additional info.
taken from http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Have you tried running SSMS in elevated mode, and do you have the latest SP installed on the client?
I would assume that this is because Vista runs most applications in isolation from either other.
I would recommend that you either set the DMZ username and password to match the internal domain username and password, or use named pipes to connect.