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.
Related
i publish an mvc3 application on a webserver IIS7 and i want to connect my application with a remote SQL server ( different machine)
here is my connection string:
connectionstring="server=server;database=db;user Id=user;password=psw;user instance=false" providername="System.Data.SqlClient"
i m using entityframework.
i also added the user in the connectionstring to security folder under database in sql management studio with dbo rights.
the problem is i get an error : failed to open a session for the user
SQL exception (0x80131904)
Have you checked the user mapping for the login?
You can find the logins under the server folder security -> logins.
Check there is a login mapped to the database user. Select the appropriate login -> properties -> user mapping tab.
The fact that a user exists in a database, does not directly mean that there is a valid login associated with that user. Ensure that a login maps to the database user and that the user has the required database role.
After hours of research i just figure out that adding the whole groupe of computers (Domain\Computers) granted me the access to the database. i changed my connectionstring to use integrated security= sspi. From the beginning it was a Connection problem.
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.
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.
I am having issues implementing SqlSiteMapProvider using the Wicked Code article. I am using VB.NET and SQL Server 2008 - and the OnSiteMapChanged event is not firing (the SqlDepdencyCache just seems to simply be not working at all).
The article states "You also need to run the ASP.NET worker process with dbo privileges for SQL Server 2005 cache dependencies to work automatically.)"
I don't understand what this means. I know what the ASPNET user account is and that it runs aspnet_wp.exe which is basically the ASP.NET run time as I understand it. I know what DBO privs are on SQL. But my SQL and web servers are on different machines, and ASPNET is not a domain account. And it seems crazy to make it one to try to simply get the SqlDepdencyCache to work, and I have trouble believing everyone is doing this?
Anyone have any clue what I'm missing here?
Thanks very much
EDIT: I FOUND MY ISSUE!!! SET NOCOUNT ON INSIDE MY STORED PROC WAS CAUSING IT!! BEWARE AS THIS IS NOWHERE IN THE MSDN DOCUMENTATION!!!!
Your worker process identity needs to be changed to either a domain user OR a user with a matching username/password on both the web and database servers. The SQL Server would also need Windows authentication (or Mixed authentication) enabled.
Under IIS 5 (Windows XP/2000), you need to modify the ASP.NET Process Identity in the machine.config file.
Under IIS 6 / 7 (Windows Vista/7/2003/2008/R2) you should just be able to modify the Application Pool identity. If this doesn't work, enable <identity impersonate="true" /> in your web.config.
SqlDependencyCache uses SqlDependency and SqlDependency deploys at runtime a set of services, queues and stored procedures in your database as part of its infrastructure. You can read this article on more details what really happens The Mysterious Notification.
When you create your site map provider, you provide a connection string. This connection string specifies either a SQL login and password, or it specifies that SSPI (or Trusted, or Integrated) Authentication should be used. When a user and password are provided then this user is used to log in into your application database (the ASP database). When SSPI is used then the conenction is made using the ASP thread identity, which is either the app pool identity or the impersonated user identity. Whichever login ends up being used, this login must have the priviledges necessary to deploy the SqlDependency infrastructure (create a queue, create a service, create a stored procedure). The simplest way is to simply make this login's user in the database member of the db_owner role (which is the correct wording for what the article calls 'dbo priviledges').
So depending on yoru connection string, your app pool identity and your impersonation settings, the database user that corresponds to the login used by the map provider must be added to the db_owner role. I can't tell what you need to do, because it all depends on the variable factors enumerated above.