I have created a group on AD, and configured this group to have access to my SQL Server. With it, any .Net app, SQL Server and SSIS are able to connect to SQL Server using any AD account that's on that group, they just need to set Trusted Connection/Windows Authentication.
Now I need to do the same on IIS apps. But I have never configured IIS and don't know how to do it. I Googled it, but everything refers to user authenticating to IIS using NTLM, not IIS connecting to SQL Server.
For Server2008 and higher you will likely want to use Application Pool Identity. This article helped get me going when I set up an IIS / SQL Application.
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
EDIT:
Specifically where it demonstrates how to use a built in account there is an option to choose a custom account.
https://thycotic.force.com/support/s/article/Running-Secret-Server-IIS-Application-Pool-with-a-Service-Account
EDIT2:
Using windows auth - https://blogs.msdn.microsoft.com/chiranth/2014/04/17/setting-up-kerberos-authentication-for-a-website-in-iis/
Related
I'm trying to set up impersonation/delegation for a web application using ASP.NET 4.5/SQL Server 2016. The goal is to use the Windows authentication on the web application and the SQL Server.
I reproduced on Azure a setup similar to the one which will be used for production, but I can't seem to find what is making the impersonation not working.
Azure VM #1 [machine name: test-iis-server]: Windows Server 2012 running IIS 8.5 and acting as Active Directory Domain Controller
Azure VM #2 [machine name: test-sql-server]: Windows Server 2016 running SQL Server 2016
Azure VM #3 [machine name: test-client]: Windows 10 machine for simulating a user connecting to the website
I created an Active Directory domain named TEST. It is possible to connect to the 3 machines with users created in Active Directory.
IIS Web server configuration:
In the web.config file:
Authentication mode = Windows
Identity impersonate = True
validation validateIntegratedModeConfiguration = False
Integrated security = SSPI
In IIS Manager:
Windows authentication = Enabled (Kernel-mode authentication = Disabled, Providers = Negotiate:Kerberos)
ASP.NET Impersonation = Enabled
Application pool = Integrated Managed Pipeline (Identity = Custom Identity: test\my-svc-account)
In Active Directory Users & Computers
For each computers (web server, sql server and user computer), I went into Properties and checked in the Delegation tab Trust this
computer for delegation to any service (Kerberos only).
SQL Server Configuration
I did not setup anything here. I assumed that ASP.NET will use the credentials of the user logged in the web application to access the
SQL Server database.
Edit: SQL Server service account: test\my-svc-account
Results:
If I don't use impersonation in the web application and use a defined user/pwd login created in SQL Server, my application works normally and I can get the Windows user credential if I want.
Using impersonation, I get a SQL Server connection error when I open the web application page: Login failed for user 'TEST\test-iis-server$'.
Expected behavior:
The web application will log into SQL Server using the credentials used to log into the "test-client" machine.
I've read a lot on how to implement the impersonation/delegation for my solution, but can't seem to find what's wrong. Anyone has any idea where the proble might come from and how I can resolve it?
Edit #1:
From what I've read, it seems like I need to setup SPNs. I'm confused about how to set them up correctly for my double-hop scenario.
I have created a user account in Active Directory to act as a service account. I've set this account to be trusted for delegation.
I use this account as the identity for my application pool in IIS and as the service account of the SQL Server instance.
Yes, you do need to configure SPNs for both the ASP.NET app pool identity, and the SQL Server service account.
It's relatively straightforward, but you need to make sure you get the right values.
In AD Users and Computers find the 'my-svc-account' account and open the properties. Navigate to the attribute editor tab (if you don't see it, enable advanced features through the ADUC 'View' menu). Find the servicePrincipalName attribute and edit it. Add the following:
http/servicename.foo.com
http/servername <== optional
Where service.foo.com matches your DNS name. If this is a CNAME, you need to also include the underlying A record name as well. So if servicename.foo.com maps to whatever.cloudapp.net, you need to add an SPN for whatever.cloudapp.net. This is for IE, because IE is ...dumb... and trying to be smart (it resolves the DNS down to lowest named record and requests an SPN for that).
Then do the same for the SQL Server service account.
MSSQLSvc/sqlserver.foo.com
MSSQLSvc/sqlserver <== optional
This needs to be the FQDN of the SQL Server host.
Lastly, you need to enable Constrained Delegation between the App Pool identity and the SQL Server service account. This is the 3rd radio button in the delegation control. Add the SQL Server SPN as a delegated target.
Restart IIS and SQL. Try browsing to the app. You should now see it connect to SQL as your named user.
What I want to do is:
Allow anonymous users to access my ASP .NET site.
Use Windows Authentication for the site to access Sql Server. It will log in to Sql Server with a domain account set aside especially for the site (and preferably do everything under the same account).
Every article on the Web tells you to do this:
<authentication mode="Windows"/>
<identity impersonate="true"/>
in Web.config. However, I gather that this is only if you want users to log in with Windows Authentication. It has nothing to do with the server logging in to SQL Server (except that the combination of the above 2 implies that users' authentication will also be used to connect to the database). Is this correct? Given that my Windows account has access to files on the server and the database which the site is connecting to, this seems hard to test....
It seems that if I:
set the App Pool Identity to the domain account
enable Anonymous Access on the site using the domain account
use a connect string with Windows Authentication
then the site will connect to SQL Server via Windows Authentication. Also, it will use the domain account as long as impersonation is off. Is this correct?
in Web.config. However, I gather that
this is only if you want users to log
in with Windows Authentication. It has
nothing to do with the server logging
in to SQL Server
This is partially true. The impersonated account will be used to logon SQL server if delegation is setup properly. You didn't see this because in most of the environment, delegation needs to be explicitly setup. Delegation is a more powerful form of impersonation and makes it possible for the server process (in your case, IIS process) to access remote resources (in your case, SQL server) while acting as the client. For more information, you can google ASP.NET Delegation. I said it's partially true because in some simple environment, you don't even need any special configuration. The delegation is just working. For example, if you have SQL server running on the same machine as the IIS server. Another case is that you have your IIS server running on an Active Directory domain controller (very rare). In these two cases or on a machine with delegation configured properly, your above statements will be wrong.
It seems that if I:
set the App Pool Identity to the
domain account
enable Anonymous
Access on the site using the domain
account
use a connect string with
Windows Authentication
then the site
will connect to SQL Server via Windows
Authentication. Also, it will use the
domain account as long as
impersonation is off. Is this correct?
Yes, this is correct.
Given that my Windows account has
access to files on the server and the
database which the site is connecting
to, this seems hard to test....
It's easy to test if you have two domain accounts (or one domain account and one local account). Set the App Pool identity to use your DomainAccount1. Grant only DomainAccount1 to have permission to access your database. Access your web app on another machine using another accound (either domain account or local account). Test if the web app can properly access your database.
If I'm following you correctly, you are right; You do not want to use impersonation/authentication to do what you want to do. Set the App Pool identity appropriately, and assure that user account has appropriate access to SQL Server.
Instead of using a Windows Account you can create a separate Sql Login i.e. a username/pwd and use that in the connection string instead.
I have an internal website that is using integrated windows authentication and this website uses sql server & active directory queries via the System.Directory.Services namespace.
To use the System.Directory.Services namespace in ASP.NET I have to run IIS under an account that has the correct privileges and importantly have impersonation set to true in the web config. If this is done then when I make a query against AD then the credentials of the wroker process (IIS) are used instead of the ASPNET account and therefore the queries will now succeed.
Now if I am also using Sql Server with a connection string configured for integrated security ('Integrated Security=SSPI') then this interprets the ASP.NET impersonation to mean that I want to access the database as the windows credentials of the web request not the worker process.
I hope I'm wrong and that I've got the config wrong, but I don't think I have and this seems not to be inconsistent?
It should be noted I'm using IIS 5.1 for development and obivously this doesn't have the concept of app-pools which I believe would resolve the problem.
Following the documentation if you want to impersonate a SPECIFIC user, you must put the username and password in the web.config file, so that it uses that same user account for all requests.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.
I am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?