I used to just put my server name and my sql credentials to connect. Now, not connecting. My other domain login can connect to OTHER servers.
When I run the app in Development, it works. Localhost it does not. So, I know the server connection is good. Something with my networking, after I got a new computer.
Related
I am working on an ASP.NET project. My database is SQL Server.
When I run the project against my local server, the connection is established. But as I put my project on GoDaddy Server and when I try to login, I found that no connection to SQL Server can be established. I am not able to login.
In both cases, I am working with an online database on GoDaddy.
Please help - is there some setting that has to be done on my hosting server?
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
Why I am not able to connect to remote server from asp.net website whereas it is connecting from SSMS
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
I tried all the possible solution suggested in this link
I checked Followings as given in the above article, they are enabled/running
SQL Server is up and running.
TCP/IP enabled in SSCM
Opened port in Windows Firewall
Remote Connection enabled
SQL Server Browser Service running
I searched for sqlbrowser.exe but it is not found in the given directory.
Finally I switched off Windows Firewall but still it is not working.
UPDATE: we are connecting to sql server using a custom user created on sql server (not sa )
I have user account credential to Remote connect to server.
I tried to change LogOn to my credentials (administrator) . in Windows Services SQL Server (MSSQlServer) and SQL Server Agent (MSSQL Server) services.
Double check your connection string - are you connecting to a hostname that needs to be added to your Hosts file? For example "dev-sql1" but without a matching entry in dns or hosts file.
If you have created a custom user, can you check if logins are disabled for the user?
In SSMS, goto Security, right click user, Properties -> Status, Login - Enabled.
Hope this should fix it.
Three possibilities and they are not mutually exclusive.
Most hosting providers disable remote connections to SQL servers. Check with RackSpace if blocking port 1433
The SQL Server needs to be reconfigured to accept remote connections. See http://support.microsoft.com/kb/914277
You have to use a different connection string. See http://www.connectionstrings.com/sql-server and look for Connect via an IP address
I got the same issue but with mysql server. Rack space had two mysql server address. One for connecting from outside their local network and one for connecting from inside the network. you will have to use the address that is required to connect from inside the network.
I am trying to connect an ASP.NET 2.0 application hosted on a client machine to an SQL server 2000 instance which is installed on a domain controller running windows server 2003 (I appreciate this is not best practise, but it is something I cannot change). I am using SQL server authentication, not Windows authentication.
During debugging, the following error is displayed at the point the 'connection' is attempted within the web application (not on running any object within Sql Server):
"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"
I have done some research, and have checked a variety of things:
1) I am certain the conection string is correct - in fact I built a little Windows app that uses the same connection information and connection succeeds...
2) This is limited to the web application - a windows application running on the remote client machine connects just fine using the same connection string (see 1).
3) The firewall settings on both computers do not prevent the connection (see 1).
4) I can ping the windows 2003 server (see 1)
5) The SQL Server credentials definitely have the rights to the objects needed
6) If I (temporarily) put the web application on the windows server 2003 and run it, it loads and runs fine (using a browser on a separate machine, or on the client machine I am trying to connect) - suggesting this is only an issue with a remote connection, and confirming the connectivity between the machines again, and also confirming the necessary security right of the SQL Server user.
7) I can start query analyser on the client machine and using the same SQL server credentials, can run the same queries on the target database just fine.
Stumped. Please help!
You need to go into the SQL Server Configuration Manager and make sure the Named Pipes option is turned on. It is not turned on by default when you install SQL Server.
Because of the research I did in the original question covering the ability of a windows app to connect but not the ASP.NET app to connect from the same machine, and the confirmation the web app was working on the server itself, I was convinced SQL server was set up correctly, that connectivity and firewalls were not a problem - it must have been a difference in the security credentials of the windows app versus the web app.
The windows app runs in the security credentials of the logged on windows user and authenticates using that, whereas the webapp runs in a restricted account and does not pass these credentials over when connecting to SQL server by default. I simply added to web.config, which impersonates the user account within which the web app runs, and it all worked!
Problem solved.
I have problems connecting to my database server. The database server is not local, I am connected via its IP address.
It works fine in my development machine. After publishing the website to my server, it can not connect to my database server.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
Why can't my publish server connect to the database server, whereas it works fine through the development machine?
I often had that problem. Mostly it's because of two problems.
Open the SQL Server Configuration Manager.
Check if the SQL Server Network Configuration supports TCP/IP, if it's disabled, enable it.
e.g. SqlServer 2005 Network Configuration, Protocols for SQLEXPRESS
Open the SQL Server Management Studio
Click on the Sql Server Properties (right click on the server name and
select properties).
After that, select the page "Security" and switch the check to "SQL Server and Windows Authentication mode".
That's all.
I'll attempt to go two for two on the psychic debugging for today...
I will assume that you are not using integrated security? If so it might explain things as the account on your local machine probably has permissions, but the SYSTEM account that is running on the server does not. Just a shot in the dark though.
It sounds like your server can't make the network connection, rather than a security issue.
Ensure that any firewalls on both the DB and app servers allow traffic on the port (1433).
Ensure you're able to ping or tracert from both machines.
Is it your first time you publish your website on the web server ? if it is , Are you sure you have set your connection string properly ?
You need to create a login ( of curse a password for that too ) and the IP Address of that SQL on the web server .
So you need IP Address of the sql server host , Database Name , UId , Pwd .
I will agree that this sounds like a network issue and not a security issue.
Remote into the web server and ping the DB server by IP address. If this does not work, your server cannot see the DB server via that address (different subnet, incorrect firewall/proxy setup, etc). There may be a proxy address you must use to get to the DB server from the web server, or your web server may also be the gateway and IIS doesn't know to look for the DB server on the LAN. If it does work, the computers may not be talking on the same port, or the firewall may be blocking that port exiting the web server.
I have spent hours trying to connect to SQL server using sqlcmd. I disabled my firewall, checked all ip listed in "Protocols for SQLEXPRESS", edited my hosts file. I tried using different ips and machinename to connect to the server. But none of work worked. After hours of investigation, I found out that I made absolutely stupid blunder making me unable to connect.
I want to remind people that the connection string is not case sensitive. But the option is!!
what i did is I put
sqlcmd -s .\sqlserver
But the correct string is
sqlcmd -S .\sqlserver
so watch out, people