I need to set up a "throw-away" instance of SQL Server 2008 for students to test a program for a few weeks. SQL Server 2008 is running on a virtual instance of Windows Server 2008. The server is not a member of the domain. The client computers that need to connect to the SQL Server are domain members, as are the student accounts. The client program expects to connect with Windows Authentication. This would all be very simple if the server were in the domain; despite lengthy discussions with the school's IT, this is not going to happen...
So: I need to configure the SQL Server to accept connections from these clients. I'm no sys-admin, so my best guess (based on this article) was:
Enable the Guest account on Windows
Add "NT AUTHORITY\ANONYMOUS LOGON" to the logins accepted by the SQL Server
Set "Network Access: Allow anonymouse SID/Name translation" in Local Security Policy
Add the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TurnOffAnonymousBlock and set it to 1
By my reckoning, that should have done it, but the clients still cannot connect. Can anyone give me a recipe for getting this to work? Basically telling the SQL Server to accept connections from anyone and everyone?
p.s. No security worries: this is all behind the school firewall, and I will reset the instance when we are done.
In order for two machines to connect using Windows Authentication, one of two things must be true:
The machines are in the same domain, or
The machines are in the same workgroup and the Windows account has the same password on both machines
If neither is true, then the only alternative is SQL Authentication (SQL Server-specific username and password).
Related
I have a computer with several SQL Server instances installed - 2008, 2012 and 2016. From this computer there is no problem to connect to any of them using Windows Authentication.
Now I try to connect to the SQL Server 2016 instance from another computer. On the server computer I've created the appropriate Windows user and SQL Server login. But when I try to connect to this instance from the different computer, the login fails.
Finally I've managed to connect to SQL Server 2016 database engine using following server name:
TCP:ALEXMWIN81,49602
But when I try to connect to the SQL Server 2016 Analysis Services, the login again fails.
Can anybody give some advice on how to connect? All instances are very important and re-installation is a problem.
Thanks in advance. Alexander Mitchenko
When you say
On the server computer I've created the appropriate Windows user and SQL Server login.
This makes it sound like you are creating a local windows login on the server machine. It should be noted that in order to use Windows authentication both your connecting machine and the server need to be on the same domain.
Creating a SQL login is a separate authentication process called "SQL Server Authentication". When you use this methodology you connect with a username and password only. For this process you would connect by putting the login credentials into a connection string.
Do you have multiple domains? This can cause problems.
Cross Domain SQL Server Logins Using Windows Authentication
Does the SQL instance expose all the required ports to the internal network?
https://msdn.microsoft.com/en-us/library/cc646023.aspx
Is the server running a Windows Firewall?
What software are you connecting from?
I would like to connect to the company's SQL Server 2014, where I am working at, with my computer using windows authentication. I need this to deploy from my machine SSIS packages, without having to access remotely our server's machine.
I have been trying to add a login with my computer name plus my user as MY_COMPUTER\USER, but I keep getting an error, which tells me the it wasn't able to find the domain of my computer.
So, how can I connect my computer to our SQL Server using a windows authentication?
CREATE LOGIN [DomainName\Username] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
Your local computer name isn't part of this at all. DomainName is the name of the windows network domain name that your SQL server would be joined to in this case. If your SQL server is not joined to a domain then that is a different scenario and I can't test but I would think you would use the computer name of the SQL Server in place of domain name and then the name of the local user....
Anyway, do you know your Domain Name?
DomainName\Username
If not joined to a domain try
SqlServerComputername\Username
We have a windows network domain joined with our SQL Server. I had already created a user for my computer on our windows network, but I wasn't logging in using the new user.
I have installed SQL Server 2005, the SQL Server instance name is SOSO, the machine name is HERO, I tried to connect from another computer using SQL Server Management Studio:
Server name: HERO\SOSO
Authentication: Windows Authentication
But I didn't succeed.
SQL Server is enabled to be connected remotely.
So what is the problem?
Windows Authentication uses the Active directory user from the connecting machine to authenticate with the database. Does it have the right permissions to access the database? Maybe try authenticating with a SQL Server database user first. Maybe you've created a SA user on installation, try connecting with that.
But as the other replies also tell, first check network / firewall connection and please provide us with the error message.
So I have a server, being hosted by an external hosting provider. To work on the server, I just need to remote connect with an IP address, a username, and password. When I remote connect, I can open SQL Server Management Studio and work on the databases. I use:
Server Name: (local)
Authentication: Windows Authentication
Username: SERVER\Administrator (Administrator is the username to remote connect)
I would like to connect to the server databases from SQL Server on my local machine. I obviously can't use (local) as the Server Name, and I can't use Windows Authentication.
I'm terrible with configuring things like this, and I really don't even know what to search for. Do I need to set up something in SQL Server on my server? Or can I use the credentials for the server to connect?
You probably won't be able to do this as the firewall will block the port that SQL Server communicates over. The hosting provider probably won't allow this traffic over their firewall as it's a big security risk.
Essentially you're stuck with the remote desktop.
The other possibility is a VPN arrangement or SSH tunneling. See if your provider can support an IPSEC VPN. If you can set up a VPN then you should be able to connect to the server that way.
There are going to be two issues.
The ports will need to be open on the remote server to connect from your machine to the server
When using Windows Authentication, there will need to be a trust relationship between SERVER and the authentication domain for the account running SSMS on the local machine
You can get around 2 by making a SQL Server account in the server (if you have rights to do that) and logging in as a SQL Server user instead of relying on a domain controller for authentication.
1 is not as easy to get around without some kind of VPN or other tunnel. Once you set up a SQL Server user, just try to connect to the machine by IP address instead of (local).
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.