I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.
Related
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
I have deployed a couple of reports in SSRS2012, the report uses the user's windows token to do some verification. When testing the report in VS I successfully read the windows token but when I deploy to SSRS token is empty.
I did configure all data sources to use windows authentication and to impersonate the user.
any ideas?
Thanks
I'm a little unclear on the specifics here, but I'm thinking the problem is with the authentication method you're using in IIS.
Check out this other question:
Why does Windows/Integrated Authentication in IIS not pass user credentials to SSRS and SQL?
The versions are a bit different (SSRS 2005) but I think the issues here are the same. I won't get into it too much, because the answer in that link explains it better than I could, but essentially, it works from Visual Studio because your Windows Token is the one making all the requests. When you deploy to IIS, however, without explicitly configuring Windows Authentication and Identity Impersonation, the requests are being executed as the App Pool User, not the user using your web app. I hope this helps!
Sorry my question might be duplicate but i dint find any correct solution.So im posting this question again...
First i have deployed a DNN website with sql server authentication.Site was working fine.
Later we re installed the sql server 2008. So im trying to give windows authentication to connect the site.
In web config connectionstring:i have removed the username and password and gave Integrated security="true" .
In IIS :Site -> Authentication -> windows Authentication ->enabled and all others disabled.
once i browse the site is redirecting to DNN install Wizard
Need Help.
In SQL Server did you configure the Windows account that the application pool (in IIS) is using to have DBOwner access to the database?
Also make sure to change BOTH connection strings in the database.
Depending on what version of IIS you are on, that account might differ. Older versions likely would use "Network Service" while newer versions might also use "Network Service" or an application pool specific account like "iis apppool\dnndev"
You'll also want to make sure that you aren't trying to assign a DOMAIN account to the database, unless of course that is what IIS is configured to use (as opposed to a local account)
We have an active directory domain (let's call it foodomain) and a domain user account (foodomain\fooAppPoolUser) used for the IIS application pool identity.
We want to run the app pool under this user account and not under Network Service or the new AppPoolIdentity as we have to access SQL server and have multiple applications on IIS (with own app pools) accessing different databases.
The problem is that I can't find a clear HOW-TO explaining, which user rights have to be set for this user account and how IIS has to be setup so that this will work.
First I got errors (unfortunately I can't remember which ones), then I added fooAppPoolUser to the local admin group (Administrators, I know, was only to test), then it worked. Now I removed the user again, restarted IIS and it still works.
So I'm confused a bit and would like to know, how the configuration/setup has to be to have it working.
Somwhere I read, that the account needs to have the "Impersonate a client after authentication" user right. That's the reason I added the account to the Admin group (the user rights assignment is blocked via group policy, but this can for sure be changed if really needed.
I hope I was clear enough what the question is and hope somebody has an answer.
It's frustrating that this information is so hard to find, since some security admins seem to enjoy the cruel and unusual punishment of changing default policy settings to thwart installing apps within IIS.
Here's what I believe you should do to enable an account to work as an ApplicationPool identity:
Run aspnet_regiis -ga DOMAIN\USER to add permissions to access the IIS Metabase. (Exactly what that means, who knows?) aspnet_regiis reference
Add the user to the IIS_IUSRS group. This may be done automatically depending on the IIS configuration setting processmodel.manualGroupMembership but easiest to add it yourself.
If security policy is using windows defaults that's about it. If the security policy is locked down you may need to enable specific user rights for the account. The ones you have by default for ApplicationPoolIdentities (which seems a good place to start but not necessarily all required):
Access this computer from the network
Adjust memory quotas for a process
Allow log on locally
Bypass traverse checking
Generate security audit details
Impersonate a client after authentication - (Often not available by default on locked-down environments)
Log on as a batch job - (Often not available by default on locked-down environments)
Log on as a service - (I'm not sure this is needed)
Replace a process level token
If you're using windows auth and Kerberos (provider=Negotiate) then depending on the URL and if kernel-mode auth is on you might need to set up an SPN. I suggest switching to NTLM if possible. Otherwise, see articles below about SPNs and find a friendly domain admin to add them for you.
Fun reading:
Default permissions and user rights for IIS 7.0, 7.5, 8.0. This is the best reference, see the user rights at the bottom.
User Rights (on Windows Server 2008, but still interesting and helpful as it's a long article you can CTRL+F to find IIS-related comments)
User Rights Assignment on Server 2008 R2+. You have to drill into each right to see what it mentions about IIS.
How To: Create a Service Account for an ASP.NET 2.0 Application - pity there's no more recent version of this article.
SPN Checklist for Kerberos on IIS7/7.5
How to use SPNs - applies to IIS6 or to 7/8 if Kernel-mode authentication is turned off.
The reason why you application worked AFTER removing Administrator rights is that your application was compiled to the Framework temp folder using the administrator rights - Your application worked after removing the administrator rights because the application was compiled. If you update your application and it requires recompilation, the app pool account will need trusts again.
First I got errors (unfortunately I can't remember which ones), then
I added fooAppPoolUser to the local admin group (Administrators, I
know, was only to test), then it worked. Now I removed the user again,
restarted IIS and it still works.
I found the following link answered a similar question I had: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Basically, ApplicationPoolIdentity is a virtual user account that still behaves like NETWORK SERVICE, but without some of the down-sides; each app pool has it's very own ApplicationPoolIdenity account created with it.
More detailed information can also be found that is also specific to IIS 7.5 Application Pool Identities.
I am working on setting up my report server to use a web service as an XML datasource. I seem to be having authentication issues between the web service and the report with I choose to use Integrated security. Here's what I have:
1) I have a website w/ an exposed service. This website is configured to run ONLY on Integrated Security. This means that we have all other modes turned off AND Enabled anonymous access turned off under directory security.
2) Within the Web.config of the website, I have the authentication mode set to Windows.
3) I have the report datasource set to being an XML data source. I have the correct URL to the service and have it set to Windows Integrated Security. Since I am making a hop from the Browser to the Reporting Server to the Web Service, I wonder if I am having an issue w/ Kerberos, but I am not sure.
When I try to access the service, I get a 401 error.
Here are the IIS logs that I am generating:
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 0
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 5
Has anyone worked out this issue before? Thanks!
It does sound like you are experiencing the "double hop" issue. Is it possible to create an account on your web service that the reporting server uses explicitly instead of passing through the users credentials?
There's a simpler solution if you dont want to muck around with Kerberos... although the user experience is less desirable.
On the Data Source...If you check the "Credentials supplied by the user running the report" and the "Use as Windows credentials when connecting to the data source" then the user will be promoted to log in when they run the report. Since the credentials are being supplied to the SSRS server it's only a single hop from SSRS to the webservice... thus avoiding the double-hop NTLM authentication problem.
It's less user-friendly, though, since you have to log in to run the report.