I have a local windows managed service that is trying to connect to a local instance of SQLExpress and am hitting a brick wall wrt the connectionstring / the authentication that the local service needs to use.
Here is the config for the managed service
<add key="..." value="Data Source=<machineName>\SQLEXPRESS;Persist Security Info=True; Integrated Security=True" />
The interesting thing is that this works but only provides access to the master db. It does not give any access to the actual db that the service needs. I have tried all sorts of possibilities in SQL Management Studio re giving access / security / user but to no avail.
I have tried using initial catalog but get a security exception
<add key="..." value="Data Source=<machineName>\SQLEXPRESS;Persist Security Info=True;inital catalog=<dbName>; Integrated Security=True" />
I am also working on the assumption that
a. The Log-on used by the managed service is a red herring and this is indeed a SQLServer issue.
b. If the SQLServer were not local then the managed service would need AD credentials.
To gain access to a particular DB other than master you need to add:
"Initial Catalog=MyDatabase;" (without quotes) to your connection string.
The service logon account must be granted logon privileges to SQL Server Express
The service logon account must have a user mapping in the database(s) you wish to access from the service.
The last two steps can be accomplished from SQL Server Management Studio.
Happy coding
Related
I have an MVC application that connects to SQL Server (I used a database first setup with ADO.NET Entity Framework 6.0). When I debug on my laptop it connects to the SQL Server correctly and renders the page without issue. But when I publish and connect to the remote server (which also is hosting the SQL Server instance) I get an error: Select permission was denied. Of note is that this is set up to only work when connected to the corporate network (or with a VPN), and the server is intranet only.
I have been looking at potential solutions, and the user account on the database has db_datareader and db_datawriter permissions. My connection string calls for integrated security=True.
I access this same database from desktop applications using those settings with no issues, so I am thinking that there is a difference with the way IIS is evaluating the user.
The server is set up to assign everyone into a single account for the purposes of database access, so all of the DOMAIN\USERS are mapped into a single account called DOMAIN\MyDatabaseUser.
This user has the correct permissions in the database/security/users property window.
I took a look at an answer for a similar issue that referred to the IIS Application Pool, but that issue was getting login failure, which I am not seeing.
Here is my connection string:
<connectionStrings>
<add name="PMToolsEntities" connectionString="metadata=res://*/Models.PMToolsModel.csdl|res://*/Models.PMToolsModel.ssdl|res://*/Models.PMToolsModel.msl;
provider=System.Data.SqlClient;
provider connection string="
data source=SERVER\MySQLExpressInstance;initial catalog=MyDatabase;
integrated security=True;
MultipleActiveResultSets=True;
App=EntityFramework""
providerName="System.Data.EntityClient" />
I have tried setting integrated security to SSPI but I get the same result. I also, for grins, removed the integrated security setting entirely and then I get a login failure (login failed for user '') as expected.
Here is what the permissions look like for MyDatabaseUser:
I basically added everything except the deny items to be sure, but I'm not getting in still.
Here is a link to what ultimately helped me (along with a patient IT guy who let me browse around on the server that I wouldn't normally have access to).
On Windows Server 2012, in the IIS MMC snap in I could see that my web site had an Application Pool added specifically for the site called MySite. Windows automatically creates a virtual user that needs to be added to the SQL Server Logins (not the database users) called IIS APPPOOL\MySite. The trick is that you must not use the search function in SSMS as it will replace IIS APPPOOL with the ServerName and therefore fail to resolve the account.
I have an ASP.NET WebAPI that is calling a SQL Server (currently 2008, but will migrate on something newer soon). Authentication is Windows authentication. I have given the IIS Apppool that executes the WebAPI the rights to access the database.
When I use the following connection string, everything works:
Server=localhost; Database=LPG; Integrated Security=SSPI;
For the production system, the WebAPI and the database server are probably on different machines, so I want to use the name of the server instead of localhost.
Server=my.server.com; Database=LPG; Integrated Security=SSPI;
With this connection string, I get the following error.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
This is probably because the IIS APPPOOL - User is a local account and when calling my.server.com it can't use local accounts.
Does anyone knows how to resolve that problem?
Thanks in advance,
Frank
The problem is your production server may not be setup for delegation. The web server and the db server must have a relationship so the user on the browser flows through to the database.
I am using ActiveDirectoryMembershipProvider and want to connect to Sql Server with Integrated connection using user identity.
"Data Source=Server;Initial Catalog=maindb;Integrated Security=True"
How to do it if it is possible?
By default
Data Source=Server;Initial Catalog=maindb;Integrated Security=True
will use ApplicationPoolIdentity in MVC.
You can grab Username/Password after using ActiveDirectoryMembershipProvider to connect to database with
Integrated Security=False
create Windows user who will be authorized for running app pool in IIS and connect to SQL server on the level you need, not the SA level. Make sure that user have SQL server authorization just in case.
Make sure that your site is using that user to run in Web Server security settings.
Create app pool and assign user to run it and to your site.
That should take care of your question.
I'm connecting to a remote database. The connection works for ASP.NET Development Server, but is failing since I switched to using IIS. Here's my connection string:
<add name="ConnectionString"
connectionString="Server=SQL-NWSS-048\SHRDDEV01;Database=PESTS;Trusted_Connection=True;"
providerName="System.Data.SqlClient" />
In Cassini, the web site is running under your account. Since your account has rights to the database, it works, as you're using Windows Integrated security to access the SQL Server. (Trusted Connection=True).
In IIS, unless you configure it differently, it runs under the <Server Name>\Network Service account, which is a local account on that server. Odds are that account doesn't have access to the database.
See How to: Access SQL Server Using Windows Integrated Security
That's relatively difficult compared to using SQL Server authentication instead. I'd recommend using SQL Server authentication, where you pass in a username/password if your situation allows for it. Just be sure to encrypt the connection strings in the web.config.
A WCF project consist of all the logic behind a desktop application (WPF) and it works well when I run it on VS 2008 with WCF selfhost. The desktop application consume services expose by the WCF and desktop application users have to login to the app using his username and password. WCF is connect with SQL Server 2008 database through LINQ and user account details also save in that database.
But after I host that WCF in IIS 7, when I login to the desktop application, it says username and password are not match. But It worked perfect in VS 2008 with self host before I host WCF in IIS 7. What is the reason for this behavior?
Please help me to solve this problem
Connection string for SQL Server database:
<add name="iSponsor.Data.Properties.Settings.test_dbConnectionString"
connectionString="Data Source=LMR-HERO\SQLSP1INS;Initial Catalog=test_db;Integrated Security=True"
providerName="System.Data.SqlClient" />
You're using integrated security. That means that the WCF service will attempt to log into the database using the IIS application pool identity.
You will either need to
grant the default app pool users (or more conveniently the local group IIS_IUSRS) permissions to access your database - needs carefully locked-down access, though, but very difficult for an attacker to impersonate this user
run the application pool as a local or domain user who does have access to the database - again need to carefully lock down this user
use SQL server authentication instead (username / password) - simplest to set up but easiest to attack