I cannot connect to my SQL Server database when running app on server.
Everything runs fine when debugging but when I run on the server as ASPNET the user is unable to login.
I created the dataabse in a test project then simply connected to this db. My connection string is
Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf;
Integrated Security=True;Connect Timeout=30;User Instance=True
So this asp app runs on IIS 5 and when deployed the initial select works fine as my gridview that I have a binding to shows data but when I run the program (update the db) I hit the following:
[SqlException (0x80131904): Cannot open user default database.
Login failed.
Login failed for user 'hostxxxxx\ASPNET'.]
I am not creating this database programmatically as mentioned previously, simply connecting to an existing database.
The database is located on my c: - but I have added user ASPNET. How can I add this db to the program as a resource rather than reference a copy on c:?
My first question is this: If you have control of the server, why are you using an attached database. From:
AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf
There is no reason to attach if you can control the server. Attach the database to the actual instance in SQL Server, not with the bastardized version you have above. The bastardized version is useful on an ISP that does not give you access to SQL tools. Beyond that, it is more work than it is worth.
The second problem you have is authentication. There are a couple of ways to handle this. The easiest is set up a SQL user to access the database. If every user will have login credentials, you can keep the Windows Authentication method, but you have to turn off anonymous access, so every user GETS authenticated. As long as anon is a choice in IIS, it will default to anon and you will have issues. The third way is to impersonate a user for database access. I guess the fourth is open your database wide open, but I don't suggest destruction of security to make something "work".
If you have your database on a server, you need to use a server-based connection string - something like:
Data Source=servername\SQLEXPRESS;database=FSR;
Integrated Security=True;Connect Timeout=30;
Your user needs to have a login on the server, and a user in the appropriate database, in order to connect successfully.
See the ConnectionStrings.com web site for a huge list of possible connection strings - and what their settings mean and how you can change those.
You need to get into your database and assign the proper privileges to the account that is trying to access the database, which in this case looks like the built-in ASPNET account. Instead of the ASPNET account, you should use the NETWORK SERVICE account. You can change this through IIS.
Related
I've been trying for just over a month to connect an ASP script here to a SQL Server database
but each time I use this connection string:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI;User ID=domain\usr;Password=pwd;
It ignores the user I specify and takes the machine name to authenticate the connection, which obviously fails.
so I change the Integrated Security value to False, like this:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=False;User ID=domain\usr;Password=pwd;
I then get an error: Login Failed for user "domain\usr" which is impossible because it works when we test the connection with it in the odbc admin app.
I asked the help of a senior and he said it's taking the user name as a database user name, but we need to make it use windows authentication, and specify which user to use.
I remember reading about this a month ago and finding that there was no way to specify a user and password when connecting using windows authentication with this version of ASP.NET.
I'm going to kill myself soon If I can't get this script to connect, someone save me please!
You've got at least 2 3 options here:
Create an App Pool on your web server which runs as domain/usr and then assign your app to this app pool, and use integrated security. Your connection string will be Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI; - i.e. drop the username and password - these are inherent in the AppPool's identity.
or (assuming Mixed Mode security is enabled) ask your DBA's to create a new SQL User (just called usr) with the same permissions as domain/usr and then change your connection string to standard security, with User Id=usr
If you enable impersonation (here and here), you can use the domain credential without changing the app pool identity. Note the point about securing cleartext passwords, and IME this typically also requires additional configuration to avoid the double-hop issue.
I am using SQL Server 2008 R2 and am facing a problem. The application that I have developed needs to be tested at client's site which is at different locality. So I plan to configure the client's machine once and then for any changes related to application I will just distribute a asp.net mvc deployment package which client can deploy on IIS. For that, I need to provide my asp.net application ability to drop and create database (through codefirst entity framework). In the present configuration, I am facing permission issue related to dropping the database. The Application somehow is unable to drop the database. Here is summary of IIS and SQL Server configuration that I am using.
For IIS, I have set the Application Pool Identity to "Local Service" as per the standard practice. The connection string in asp.net web.config file is given below.
connectionString="Server=.\SQLEXPRESS;Database=SomeDatabase;Trusted_Connection=true;User Id=someuser;Password=somepassword" />
For SQL Server Service, I have provided "Local Service" as log on, again providing the minimum access here for the service. For SQL Server Instance Logins I have defined the user and password and given complete authority ("sysadmin") role.
With this configuration in place I was expecting my IIS application to connect using the user and password created above and have the ability to drop and create the SQL Server database. But I am getting permission denied for Dropping Database. The Exception is given below.
System.Data.SqlClient.SqlException (0x80131904): Cannot drop the database 'SomeDatabase', because it does not exist or you do not have permission.
I have checked that the database exists so it boils down to permissions. Am I missing out some configuration ?
To be clear, your connection string is a bit malformed, and may not be behaving as you expect.
When you specify Integrated Security=true in your connection string, then Windows Authentication occurs. Any user id= attribute in the connection string will be ignored.
Switch to SQL Server authentication mode by dropping your Integrated Security=true attribute.
Server=.\SQLEXPRESS;Database=SomeDatabase;
User Id=someuser;Password=somepassword;
Further, the DROP DATABASE command can be executed by the database owner, a user who's a member of the db_owner role, or a user in a server admin role.
Add the database user someuser to the db_owner role.
EXEC sp_addrolemember 'db_owner', 'SomeUser';
Alternatively, if you determine that the account above should NOT be in this role (i.e. restrictive security environment, policies, etc), consider creating and using another account just for this purpose. This would likely mean maintaining another connection string. If the separation of users/roles is important enough for you, perhaps this second option will work.
I think that the real account being used on the Sql connection is the 'Local Service' because you defined Trusted_Connection=True in the connection string. Try to remove it and see what happens. If I'm not wrong, this parameter will make use of a Windows Integrated Account, the Local Service in your case.
While specifying credentials in the connection string, you either need to omit Trusted_Connection part or set it to False
Data Source =myServerAddress; Initial Catalog =myDataBase; User Id =myUsername; Password =myPassword;
OR
Server =myServerAddress; Database =myDataBase; User ID =myUsername; Password =myPassword; Trusted_Connection =False;
Refer http://connectionstrings.com/sql-server-2008 for more details.
I have installed a new web application that access a SQL Server database in a different server. I'm using Windows Authentication and get the error of:
Login Failed for user XXX
When I try to set identity impersonate="true" in the web.config file, it just throws an error
Login Failed for anonymous user
Also, I'm using forms authentication to validate users from my website and using a different application pool.
Update: connection string Basically like this:
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
Update:
My Virtual Directory has Anonymous Authentication and Windows Authentication enabled.
Typically ASP.NET runs as an anonomous account. In order to access a remote SQL Server using integrated authentication (SSPI), you'll need to have a bit more "permenant" presence. Easy way would be to shift the app pool to use the NETWORK SERVICE built-in account. Slightly trickier would be to use a named account. On the SQL server side of the equation you will need to give the same account -- either matching user/pass or NETWORK SERVICE -- proper permissions to your database.
Your DBA should be able to help.
It is difficult to provide you with an exact answer because you have not provided your connection string or info on your SQL Server config. Your best bet is to look at the IIS configuration and work out what user is attempting to access the different SQL Server. You then need to give this account access to the database. This is a common problem and most of the changes need to happen in SQL Server unless you can change the account that the web server is running under.
Earlier mdf file was in app_Data folder, and application was working fine.
When I attached mdf file into sql server. I can execute queries. But when I try to use it from asp.net application it give following exception.
Cannot open user default database. Login failed.
Login failed for user 'domain\username'
So if I understand correctly you no longer specify the AttachDBFilename but instead you have attached the database 'for real' to an existing SQL Server instance.
since you are no longer conencting to your own personal RANU instance, your application must have proper credentials to connect to the SQL Server instance where you attached the database. The correct solution depends on a number of factors, but possible answers are:
create a SQL Server login for the ASP app pool identity and grant this loggin proper access to the required database. Use CREATE LOGIN [domain\user] FROM WINDOWS and CREATE USER [domain\user]. Better still, for extra credit, add the app pool identity to a security group and grant this security group the needed permission.
change the app pool identity to an indetity that has the proper permissions already granted
if the ASP application uses impersonation and the SQL Server instance is on a different machine from the ASP application, make sure your ASP app pool is allowed to do constrained delegation.
That error indicates that you are trying to use Intergrated Security. Depending on your version of IIS and your configuration, you are probably trying to connect to the database with the IUSR or NETWORK SERVICE accounts.
The simplest fix is to use SQL Authentication. Include a SQL account username/password in your connection string.
For debugging purpose, I backedup one of QA database and restored to local machine. Since it is in my local machine, I just want to connect to it using Integrated Security=True in my asp.net application. But I am getting following error:
Cannot open database "db1" requested
by the login. The login failed. Login
failed for user "DEV-LPTP-1784\ASPNET".
Any thoughts?
Thanks.
Delete and recreate database login you use. After db restore the database user has the same name, but inner SQL Server id is different, so SQL Server thinks that server login "DEV-LPTP-1784\ASPNET" is different than db user "DEV-LPTP-1784\ASPNET"
The user that ASP.NET is running under does not have access to that database. You can either grant that user access via SQL Management Studio, or change your connection string to use a specific username and password.