I have a console application that also runs as a windows service (see: .NET console application as Windows service)
It runs a stored proc that works on my local db, however over the network it only works as a console app, the service gives "SqlException (0x80131904):Cannot find the object or you don't have permission".
The user account has db owner permissions.
The very first thing the SP does is disable a trigger on a table, that it now says either does not exist or I don't have permission to access.
I am new to windows services, is there something I am missing? Do they work differently in this regard?
Its a sqlserver 2012 instance on another devs machine over the local network.
Connection string:
<add name="XYZ_ConnectionString" connectionString="Data Source=PCNAME\sql2012;Initial Catalog=DB_Name;Integrated Security=SSPI;" providerName="System.Data.SqlClient"/>
EDIT: I have noticed that an earlier part of the service that does a select on a table from the DB is working correctly, which suggests the connection is working?
Thanks
If the select query is running correctly that seems to be a permission issue on SQL Server on the user excuting the operations.
Given that you are removing a trigger that does requires a different set of permissions that the ones needed to execute a select statement. I would suggest that you make sure the running user is getting proper access to the services, I would use SQL Server Profiler to log all the query and events to the database right after I run the application. In there I would see the queries that are failing and have a better picture of the root of the error.
You're using Windows Authentication (the part of your connection string that reads Integrated Security=SSPI;) so when you run it as a console app it is using your logged in Windows ID to authenticate.
SQL Servers can be configured to use Windows Authentication or "Mixed Mode", which supports a textual username and password (details). Note that the default is to only use Windows Authentication.
If you are able to add Mixed Mode auth to the SQL Server (or it's already enabled) then get the database admin to create a new user and replace the Integrated Security=SSPI; part of your connection string with something like this:
;User ID=*****;Password=*****;
If you are not able to use Mixed Mode auth at the SQL Server (some DBAs are reticent to do this) then you need to configure your Windows Service to start with a Windows Domain account - note that it must be a Domain account, rather than a local Windows account on your PC, because the SQL Server needs to get to a domain controller to authenticate the credentials.
Info on configuring the service's credentials can be found here, but it's little more complex than opening the service in the service manager window, going to the "Logon" tab, and selecting the account that the service should run as.
Related
I have two machines: WEB-FE and WEB-BE. WEB-BE is running SQL Server and on WEB-FE is running IIS. Both are on Server 2019, and are a part of a workgroup. They are not joined to any AD domain. We are using .NET 6.
My current working connection string is this:
Data Source=web-be;Initial Catalog=MyDb;Persist Security Info=True;User ID=MyApp;Password=thebesteverpassword
I want to connect to the database via the application pool user and not use the userid/password combo, but I haven't been able to make that happen, in spite of my efforts.
As far as I know, the Application Pool needs to be set up and run as a local user, so that when it connects to SQL Server on the other machine, the user will be the same as what SQL Server has on its side for a user.
I haven't been able to find actual instructions on how to do this step by step, which surprises me. Most everything I've seen says that AD and integrated security are the way to go, but I can't do integrated security because these two machines are not on the domain and won't be; they're in a workgroup. I am able to connect by specifying the user/password combination in my appsettings.json, but since this is not a best practice, I want to not do that.
I would like to get instructions on what the appsettings.json connection string should look like, what set up needs to be done on the FE server with IIS, and what set up needs to be done on the BE server with SQL Server, so that when I make a database call (via Entity Framework Core) I'll get the data that I'm looking for.
This should be as simple as
Create a local user with the same name and password on both server.
Create a login and user with permissions for this windows user in SQL Server.
Configure your IIS App Pool to run as this user, and use the in-process hosting model.
Use Integrated Security=true in your connection string.
I need to use data base locally. I have created database in (LocalDB)\v11.0 Server with Visual Studio 2012. Everything is ok when connecting from e.g. console application. But my application is Windows Service. trying to connect to my data base outputs with:
"... The login failed.Login failed for user 'NT AUTHORITY\SYSTEM"
Is there any solution for this? Maybe I should think of setting up other db server for it? If yes, how to set up it so that it would be visible only locally?
So i found out solution myself, how to connect instance of (localdb) from Windows Service which runs as Local System:
I used this articles:
http://technet.microsoft.com/pl-pl/library/hh212961.aspx
http://dba.fyicenter.com/faq/sql_server_2/Verifying_a_Login_Name_with_SQLCMD_Tool.html
http://social.technet.microsoft.com/wiki/contents/articles/4609.troubleshoot-sql-server-2012-express-localdb.aspx
So i shared my localdb (as in 1st article) the problem was I couldn't connect with sqlcmd named pipe np://. I found anwer in 3rd article:
When using sqlcmd, ensure that you are using the SQL Server 2012
version (found in %Program Files%\Microsoft SQL
Server\110\Tools\Binn). If you have previous versions of sqlcmd
installed, calling sqlcmd alone from the command line will most likely
use the old version (which isn't localdb-aware) since the older path
appears first in your PATH environment variable. It may be a good
idea, in general, to manually adjust your PATH environment variable so
that the 110 versions are picked up first.
This small information in fact was crucial;)
so i created user: user with password: pass321!#.
In my windows service my Sql connectionString looks:
"Data Source=(localdb)\\.\\MyInstanceShared;Integrated Security=false;User Id=user;Password=pass321!#"
Integrated security set to false value is also important.
Maybe it will help somebody.
Probably your connection string is using the current Windows User account (the account that runs the service could be the one seen on the error) to connect to the database (and that user account does not have access).
What I would do is that I would change the database to allow "mixed authentication" (this means SQL users and Windows users too) and then I would create a new user, assign that user the required permissions to work with your app and then use that userName and password in the connection string from your windows service.
You could also leave the DB as it is and add user "System" from Windows and then assign the required permissions to it. You can just add "dbo" profile to a user to make it work fast (but check security later before releasing your product).
I think that you need to allow remote connection to your SqlServer.
In the Sql Server configuration manager, under SQL Network Configuration, chose your server and check that TCP/IP is enabled.
In my case, doublic click on TCP/IP, go to the bottom "IPAll" and set dynamic ports empty and TCP Port to 1433.
Let me know if it's enough.
I have developed a Windows Service which stores and retrieves its MSSQL connection string in the registry. However I am experiencing that when my service attempts to connect with the string retrieved from the registry it blatantly ignores the UID and PWD specified.
I then compiled and ran the application as a console application and naturally that worked, since the console application was run with the rights of my own user account, whereas the service was run with the Local System account. The service connected successfully to the database when I specified that the service should be run as my own user account.
My conclusion is that when retrieved from the registry an application for some reason does one or both of the following:
Ignores the UID and PWD specified.
Automatically assume that the connection should be made in Trusted mode (Trusted_Connection=true)
It is worth mentioning that I have indeed specified Trusted_Connection=false in the connection string stored in the registry.
This is my connection string:
SERVER=.\SQLEXPRESS;DATABASE=mydb;UID=myid;PWD=mypwd
Is anyone able to shed some light on this matter? I would very much like to be able to utilize the user id and password stored in my connection string.
I take it you have SQL Server Authentication switched on?
With integrated authentication (recommended) you need to use change the service Run-As account to an account which has a SQL Server login.
I.e.
Turn ON Trusted_connection. Just ... don't turn it off.
Create a user DOMAIN\USR_MYSERVICE.
Grant the appropriate machine and database permissions to the account.
Set the service to run as that account.
Check that SQL is configured for Standard Security as specifying the username and password will utilise Standard Security not integrated. So you cannot use a windows account to access the database in this manner.
The alternative and usually preferred method is to run your service as a windows account and access using integrated security.
http://msdn.microsoft.com/en-us/library/aa266913(v=vs.60).aspx
I am working on a C# web service.
I have deployed a web service which is working perfectly on my local system but when I try to run the same service on my virtual dedicated server it is returning an error.
This is my connection string
Data Source = <serverinstance>\\SQLEXPRESS; Initial Catalog = DomainTable; User ID= <serverinstance>\\admin; Password = <Windows_Login_Password>
Before this I was using this connection string
Data Source=<serverinstance>\\SQLEXPRESS; Initial Catalog=DomainTable; Integrated Security=SSPI";
None of them is working for me. please help its really really important
Data Source=serverinstance\SQLEXPRESS;
-----------------------------------------^ only one slash here
Also make sure that the remote server can see whatever you've referenced as <serverinstance>. You may have this as localhost but your web server does not consider your machine to be localhost. It may also not be able to reach it by name, particularly if it is in a different domain.
If you are trying to use Windows Authentication, there is no way on earth you should be using:
User ID = serverinstance\admin; Password = Windows_Login_Password
Wow, never hard-code a Windows password anywhere. If you want to use SQL authentication, then set up . Otherwise you should be using this instead of User ID / Password:
Persist Security Info = true;
And ensuring that the IIS user has been granted access to your SQL Server.
Try just;
"data source=.\\SQLEXPRESS;Integrated Security=SSPI;initial catalog=DomainTable"
I believe the user name / password are generally only required for remote connections, and you must set them up for the specified DB. The above connection string should get you going on the running instance of sqlexpress on the local machine if you have not made login credentials required.
Edit
If you are using IIS to host, here is a chunk from a recent article I did for deploying and setting up App pools to work with SQL Express 2008. Even if you are not using IIS, you will still need to do something like this to get your hosting environment set up correctly with SQL Server.
Step 1 Create a DB Logon for the IIS USER
In the security section in MS SQL SERVER, need to right click users and your IIS APPPOOL(IIS APPPOOL\apppoolname, created in Section one, Step 2).Check out dp.'s answer here for more step by steps - Add IIS 7 AppPool Identities as SQL Server Logons
Step 2 Setting Permissions for the IIS USER on the db
Right click on the database name, and click properties. In permissions section add your APPPOOL user that you just created, be sure to give him the Execute \Select permissions needed .
Note: Website1 needs Execute, Select, Delete, Insert permissions as well. Website2 is also using this app pool which it shouldnt be because we dont not need to alow the user to have that kind of functionality from within the trimdynamics application. We could seperate the app pools so that our trim dynamics IIS USRS is only getting Execute and Select permissions.
If this does not help, it is hard to tell whats really going on without concrete knowledge of your hosting structure, as there are lot's of gotch-ya's when deploying from development to production environment :(
I've just finished my c# application with sql database built in 2008 r2 version
I wanted to share this database over LAN and my connection string is :
ConnectionString = #"Data Source=192.168.0.1,1433\SQLEXPRESS;user id=Rula; password=marojo;AttachDbFilename=\\192.168.0.1\Release\WEPA.mdf;Connection Timeout=30;Integrated Security=SSPI;user instance=true";
where 192.168.0.1 is the IP of the computer hosting the sqlexpress instance
when I connect to database locally from the hosting computer I get no errors, but when I try to connect to the database from the shared application I get the following error:
User doesn't have permission to perform this action.
while I mapped the GUEST user to my database on the hosting machine since I knew that if a computer try to connect to database remotly, it connect as guest.
notice: I have my application and database shared over network in the same folder, and again locally everything is ok
Please what can I do to solve this problem ????
thanks in advance =-)
If the 2 machines are not on the same domain this will fail. You might want to use sql logins
The guest account would not be used in an trusted connection. The integrated connection uses the user account attached to the process using the connection string.
http://forums.asp.net/t/822604.aspx/1
If you wanted to use integrated security, the web server would need to be configured to digest logins and then you would need to grant access to all (potential) authenticated users access to the database. This is typically not done due to the unnecessary complexity you are adding to the process. Just use sql links like Ali stated and be done with it.
Okay, I see a couple things that are wrong in your connection string.
Namely, you have defined a user id and password... then you go on to set the Integrated Security flag. These are mutually exclusive. Either it connects as the same user that the app is executing under (most likely the app pool user account) OR it connects as the user defined in your connection string.
The reason you see a difference between 7 and XP is simply that one is defaulting to using the user id / password, the other is defaulting to using integrated security.
I suggest that you visit http://www.connectionstrings.com/ in order to build a proper connection string.
Update:
Other things I see. First, AttachDbFilename can only work with integrated security. Obviously that isn't a possibility, so you need to get rid of that parameter and configure sqlexpress directly on the server to target that database file.
Second, User Instance is for desktop deployments.. not servers. Get rid of it as well because it's going to be a huge memory hog.
Third, read this: http://msdn.microsoft.com/en-us/library/ms247257(v=VS.100).aspx
There are quite a few reasons this could be happening:
SQL Browser service not turned on
Connection string using a trusted connection and you are not set up as that user (check what user your code is using by getting User from the current context)
You do not have the same protocols set up on the client (less likely)
Since it is a permissions issue, you will most likely have to set up your windows domain account in the database to use it. If that is not an option for the application users, then you may desire to move to a sql account rather than windows accounts.
problem solved !!
there was just attaching problem when the database is attached to sql server management studio it's attached as an old name or related to the computer it's copied from
Thank you everyone for your effort : )