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).
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 am setting up a system that runs on Azure but needs to access an on-premises SQL Server. I've built it out as detailed in this article. This calls for me opening port 1433 to the world which looks like a serious security problem. Is there any way to open that port and still have it secure (I know that I can have complex user ids and passwords and everything, but is there a better way to secure SQL Server)
The connection between your on-premises DB and Windows Azure Connect will be secure by default via the IPSEC protocol
"Windows Azure Connect uses industry-standard end-to-end IPSEC
protocol to establish secure connections between on-premise machines
and roles in the cloud. Unlike a traditional Virtual Private Network
(VPN), which establishes secure connectivity at gateway level, Windows
Azure Connect offers more granular control by establishing secure
connections at a machine and role level."
http://blogs.msdn.com/b/usisvde/archive/2012/03/14/windows-azure-security-best-practices-part-6-how-azure-services-extends-your-app-security.aspx
Your DB won't be publicly available, only VM's on the Azure Connect will be able to see it.
Your traditional firewall and on-premises security policies and procedures will still hide your DB in your Enterprise Environment, all you are doing is giving Windows Azure VM (Roles) the ability to see it.
I saw the comment discussion on #user728584's answer about opening port 1433. Port 1433 has nothing to do with Azure Connect, which is essentially a VPN tunnel between on-prem boxes and a collection of Windows Azure role instances. Azure Connect requires an agent to be installed on any on-prem server you're adding to the Connect Group and doesn't require an inbound port to be opened. In your case, you'd add the agent to your SQL Server box, which would then be part of the connect group and accessible directly from your Windows Azure Role instances (for the roles you add to the group). The Connect Agent then establishes the tunnel.
The Connect Agent has a special key baked in, generated for you, making it unique. But even if someone somehow obtained the installer for your specific Connect Agent, it wouldn't help at all, as you still need to add that node to the Connect Group. So, this is a secure setup.
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.
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).
How do I connect to an SQL Server remotely and administer my database objects? I need to connect to my database located on the web hosting company's server. I have the server name, IP address, my database username & password. I have an installation of SQL Server 2000 in my machine.
Can I use SQL Server Enterprise Manager for this? A step by step guide would be very helpful.
Yes, you can use Enterprise Manager (or SQL Server Management Studio, even if it's an Express version) to connect to any SQL Server (of the same or lower version as the tool you're using) you have TCP/IP connectivity to. Just launch it, enter the DNS host name or IP address in the 'Server Name' box and hit Connect.
Two things may prevent this from working:
Your SQL Server isn't set up for TCP/IP connectivity. This is the default setting from version 2005 onwards, and can be changed using the SQL Server Configuration Manager.
There is a firewall between you and your SQL Server blocking TCP/IP traffic. This is an entirely sensible construction: you do NOT want your database server to be available from the general Internet, as this is a huge security risk. In fact, if your hosting company allows this kind of access by default, I'd be looking for a different provider...
Anyway, what seems to be needed in your scenario is: a) the hosting company enabling TCP/IP on your SQL Server instance, b) them providing you with secure access to the IP address that instance is running on.
This will involve some kind of VPN or SSH port-forwarding soluition, or at least an IP filter, where only 'trusted' IP addresses can access the SQL Server (which is not a great solution, but can be used if nothing else can be implemented). You'll have to discuss these requirements with your hosting company.
Yes you can do this but how you do this will be dependent on your hosting setup.
As Brannon suggests you will need to open port 1433 on the firewall. This would be a dangerous thing to do on its own so you would combine it with a VPN. It can be quite tricky to set this up through and you could end up blocking yourself from access to the server and needing the hosting companies help to reset it.
Another option would be some of the web management tools such as:
http://www.microsoft.com/downloads/details.aspx?familyid=C039A798-C57A-419E-ACBC-2A332CB7F959&displaylang=en
http://www.mylittleadmin.com/en/welcome.aspx
It is possible, but a lot of things need to align for you to be able to connect.
Enterprise Manager and SQL Management Studio just use a standard client connection to SQL. The default TCP/IP port is 1433, but the host needs to allow that port through the firewall. If you are using a named instance, then I believe you also need to be able to connect to port 1434.
Most administrators do not allow direct access to the SQL Server from outside the firewall. In that case, if you can connect to the host over VPN then you should be able to connect directly to the server with Enterprise Manager or SQL Management Studio.