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.
Related
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'm trying to connect to a local SQL Server database but it gives me this error:
Login failed for user 'DOMAIN\Username'.
When I open SQL server and look in the Security\Logins folder then I do see the user DOMAIN\Username. This is also the user that I use to login into Windows with.
My connection string looks like this:
<add name="ServerConfiguration"
connectionString="server=localhost; database=BN_Configuration;
Integrated Security=false; User ID=DOMAIN\Username; Password=123456;"
providerName="System.Data.SqlClient" />
Anyone any idea why I can't login with these credentials?
--
Note I wish to authenticate with a user that exists in the SQL Server database. So I do NOT want to do Windows authentication with Integrated Security set to false.
It looks like you are using a Windows credential as SQL Server credential. Try integrated security = true, and not to specify user ID and password.
In your connection string Integrated Security=false is saying user ID and password are specified in the connection for an account that exists in SQL Server but is NOT a domain user. When Integrated Security=true, the current Windows account credentials are used for authentication. If it's an application it will use the user who is currently logged in, and for a web application it all depends on how your application pool is set up.
You are mixing up the definitions by saying ``Integrated Security=false` but passing domain credentials which is not possible.
Using a domain account
Set Integrated Security=true
Remove the user id and password sections.
Map the domain account in SQL Server making sure to set Windows authentication
If it's a web application, make sure your application pool is set to run under that domain account.
Using a SQL Server Account
Set Integrated Security=false
Create a SQL login, making sure it uses SQL Server authentication
Set the User ID and Password properties of your connection string to be the same details you created above.
Note: Final point, make sure the user also has access to the database you are connecting to (in your case BN_Configuration).
After moving my MVC 4 applicaiton on production the IIS is using
domain/machinename$
to access the SQL database on a different server. The SQL server is configured to accept connection from
mydomain/myuser
I'm wondering how to fix this and make it pass the correct credentials, in my connection string I have
Integrated Security=SSPI
and I deployed as my user
IIS is using the identity of the Application Pool to login to SQL server because you have the Intergrated Security setting. Change the identity of your application pool to run as the Domain/User or specify the login credentials in the connection string to SQL.
SQL Connection String with specified credentials
Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername;
Password=myPassword;
I used Custom account for the identity and it worked
I have a classic ASP app that I am trying to connect to a SQL Server 2008 database on a different server. The ASP app is being served from IIS7 on Windows Server 2008.
I have changed the web site's application pool to run under a specific windows account, that I have verified has access to the database on the remote server.
However, when I run the app in the browser, I get this error:
Application Error
Number: -2147217843 (0x80040E4D)
Source: Microsoft OLE DB Provider for SQL Server
Description: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Why is it trying to connect using NT AUTHORITY\ANONYMOUS LOGON?
Does the App pool identity not apply to classic ASP code?
How can I make this connect as a specific user?
EDIT
Here is the connection string I am using:
Provider=SQLOLEDB.1;Data Source=myDbServer;Initial Catalog=myDatabase;Integrated Security=SSPI
For a site to use the application pool identity for classic ASP, you need to change the credentials used for Anonymous Authentication. By default, the site will be set to use a specific user, namely IUSR.
Select Authentication from the IIS area of your site, then select Anonymous Authentication followed by Edit. Change from Specific user to Application pool identity.
It's advisable to use Windows authentication (integrated security) over SQL authentication so that you don't have credentials in your config files so that if those files are compromised, you don't lose control of the credentials.
Does your app impersonate the caller? You need to enable constrained delegation: Configuring Servers for Delegation.
you should specify a username and password for the connection string www.connectionstrings.com or set the IIS application to run as a specific user however that would then render a lot of the security settings in IIS obsolete.
Provider=SQLNCLI10;Server=myServerAddress;Database=myDataBase;Uid=myUsername; Pwd=myPassword;
And have a look here: aspfaq
Lastly, make sure anonymous access is disabled on the IIS site so that it actually impersonates the user you selected instead of passing the anonymous tokens through.
To cut a long story short: As part of an online database access system I'm writing I want to use the new BLOB access features in SQL 2008 - this means I have to use Windows Authentication when logging into the SQL Server; however due to it's very nature the website front end to all this uses Forms authentication with the membership data stored on that SQL server.
How do I get the web application to impersonate a user account so it can connect to the SQL server, i.e. I don't want to use the account of a user logged into the website. (Not that you could do this as the membership details are stored on the SQL server)
The webserver and the SQL server are on different machines on the same network, there is a user account set up just for the web application to use.
The connection string should look something like:
< add name="MyConnectionString" connectionString="Data Source=THESQLSERVER;Initial Catalog=TheDatabase;Persist Security Info=True; Integrated Security=True;Application Name=CRM.Sales" providerName=""/>
Where you use Integrated Security. Then your application pool should use an identity that has access to your sql server.
You would grant rights to that identity.