I've got an ASP.NET (.NET 4.0) application that uses Windows Forms Authentication. This authenticates against Active Directory and works just fine.
This web app calls an ASP.NET Web Service(.NET 4.0) on the same server. Both the app and the service are running on IIS 6.
The web service calls a SQL Server 2005 database in the same domain using "Integrated Security=SSPI" as part of the connection string.
I want the web service and the database connection to use the credentials of the logged in user of the web app.
I've tried dozens of combination of settings from dozens of web sites, but nothing has worked. I'm on my second day and haven't gotten anywhere.
Is this even possible?
In my latest attempt, I added this code in the web app before calling the web service:
svc.Credentials = System.Net.CredentialCache.DefaultCredentials;
But inside the service, User.Identity.Name returns the value of the user who started the web server.
What you're trying to do is called "delegation". It means that the end-user is authenticated with the web server, and then the web server tries to use those credentials to gain access to the SQL Server. But the SQL Sever does not trust the web server, it only trusts the domain controller. So the request fails.
Besides not working, delegation has another disadvantage. Because each user would use different credentials, SQL connections would no longer be pooled. Each credential would have its own pool. That would be a major resource hog even at low user counts.
For more information, check out this MSDN article.
TL;DR: Give up on delegation and move to SQL auth.
Related
We have an internal asp.net web application which has ASP.NET authentication and Windows Authentication enabled so that users can be logged in as soon as they connect to the website using their domain credentials (this is a requirement that we cannot change).
We are currently looking to upgrade our SQL database and understand that SQL Authentication is less secure than integrated security (e.g. https://msdn.microsoft.com/en-us/library/bb669066(v=vs.110).aspx). Currently we use SQL Authentication.
We could easily change the connection string to run using integrated security, however IIS presents the user as the domain user connected to the website (e.g. domain\greg) instead of the service (domain\WebsiteServiceUser), because IIS impersonates the user. This impersonation is needed to access their Exchange Mailbox, files and other things.
If we were to go down this path, we would have to add logons for every user (using AD groups) to SQL Server. This is possible, but in itself presents a new security issue - users would be able to create a SQL connection outside of our web application and run whatever queries they like against the database. All of our authorization could be bypassed.
Is there a way to connect to SQL using Integrated Authentication using the user that the AppPool runs as (Domain\WebsiteServiceUser) instead of connecting as the currently logged on user (Domain\Greg)?
I have a web application which is configured to run under NTLM scheme.
From the web application I am accessing a service in application server.
I am impersonating the user in the web application code which accesses the service in application server.
When I access the web application from the web server everything works fine.
But when I try to access the web application from a different client machine with same credentials the the call to service in application server is failing with access denied.
The same scenario is working in different set of machines.
Am I missing any settings?
If we setup the delegation from the app pool identity account in ADC and choose “any protocol” instead of "Kerberos only" the problem is getting resolved.
I have an application developed in ASP.NET MVC using Entity Framework / Sql Server 2008
Actually, connections to the database are made with the "sa" account.
Is it possible to use, instead of "sa" the windows final user credentials ?
This would be helpful to control more efficiently the security limitations of each user.
I use, in my application windows authentication.
Thank's !
It is possible but whole your system must run inside windows domain, users must have domain accounts and your system infrastructure must be enabled for Kerberos delegation (belongs to ServerFault). The reason is that you have two hoops in the system - first user authenticates from his client machine to your web server and then web server delegates user credentials to database server. If client computer, web server and database server are different machine Kerberos delegation must be enabled (if db and web runs on the same server you should be fine without Kerberos). Your web application will have to use impersonation and your connection string will have to use windows integrated security.
Also using end user credentials will reduce performance of your system because EF will have to maintain separate connection pool per user. Administrator of SQL server will have to give access for every single user (or user group) using your application.
Issue:
In ASP.NET 4.0, I use my SSRS 2005 server's ReportService2005.asmx web service to get a list of reports. Also in .NET, I use Entity Framework to communicate with my MS-SQL 2005 database. When I use Visual Studio Development Server as my web server, calls to SSRS and SQL work fine. But when I switch to IIS 5.1, both SSRS and Entity code produce errors. I use only Windows/Integrated Authentication in IIS.
Errors:
For SSRS, I get The request failed with HTTP status 401: Unauthorized.
For Entity Framework, I get Login failed for user ''. The user is not associated with a trusted SQL Server connection.
Attempted Solutions:
In the Web.Config I added <identity impersonate="true" /> and that fixed Entity Framework errors but not SSRS errors. I expanded the identity reference to include my username and password, and that fixed all errors.
Question:
Why does specifying my username and password fix the errors, and why does SQL say I am not specifying a username ('')? I thought Windows Authentication automatically impersonated the current user. How can I fix this without hardcoding a "service" account into the web.config?
Windows or Integrated authentication means that user is identified using windows credentials (or token) but it does not means that the request in running under that user. ASP.NET run-time will execute the request under worker process (App Pool) identity unless you configure it to impersonate some other identity.
So when you are accessing the site using development server, the server is running under your identity and so access to SSRS and Sql Server is done under your identity and it works.
When you loaded your site under IIS, ASP.NET request would be run under whatever identity is configured for the application pool. Typically this identity is local user and hence access to network resources such as SSRS or Sql Server would be denied. Adding <identity impersonate="true" username="your name" ../>, ASP.NET will run requests under your identity and that should work for both SSRS and Sql Server.
The curious case here is <identity impersonate="true" /> - under this setting, ASP.NET will impersonate currently authenticated windows identity. However, for this to work correctly, you have configure both IIS and ASP.NET on integrated authentication and deny anonymous access (in ASP.NET as well as IIS). Failing to do so may result in not authenticating current user's identity and the request would be run under anonymous user's identity (as configured in IIS). If you marked integrated authentication in IIS but not in ASP.NET then identity would not be passed to the ASP.NET request. You need to check your environment to see what exact scenario you had faced but ultimate result was your ASP.NET request was running under credential that has access to SQL Server but not to SSRS.
You also need to be aware of the 'double hop' issue - this means that your credentials can only be used twice.
If you are accessing a website using Windows Authentication and impersonation, that website can call another service as you. If that other service is another website (i.e. Reporting Services) which in turn calls another service (e.g. database) it cannot pass your credentials on again. This means that the database will throw an error if it expects credentials from the user.
I was wondering when using Windows Authentication mode in a connection string from a web application. Application itself is using Windows Authentication for authorization. Which account will be used to login to SQL Server.
Is't the web application pool account?
User account who logged in to web application using windows auth?
Any other account?
Application is running under Win Ser 2008 64 bit and IIS 7. Application pool account is Network Service.
It depends on how you configure it. From http://msdn.microsoft.com/en-us/library/ms998292.aspx and http://msdn.microsoft.com/en-us/library/bsz5788z.aspx ...
ASP.NET applications do not impersonate by default. As a result, when they use Windows authentication to connect to SQL Server, they use the Web application's process identity. With this approach, your front-end Web application authenticates and authorizes its users and then uses a trusted identity to access the database. The database trusts the application's identity and trusts the application to properly authenticate and authorize callers. This approach is referred to as the trusted subsystem model.
The alternative model referred to as the impersonation/delegation model uses the original caller's Windows identity to access the database. This approach requires that your ASP.NET application is configured to use impersonation. See the section "Impersonation / Delegation vs. Trusted Subsystem" in this document.
So depending on how you have configured it, it could use either the app pool account (not when not using impersonation) or the account of the logged-in user that is using the web application (when using impersonation).
See http://msdn.microsoft.com/en-us/library/134ec8tc.aspx for impersonation information.
It's the application pool user who connects to the database, if you specified Integrated Security in your connection string.
The problem that i was having was that my application pool account in SQL Server needed to be set to the db_owner role before it worked. I spent a long time trying to figure this out.
I was using Windows Authentication, Windows 7 home premium, and IIS all on the same computer. I'm posting this in case someone else run into a similar problem. The book i used did not say to use db_owner but the reader and writer accounts instead.