I'm working with MicroStrategy 10.3, hosted on IIS 7.5. I'm using their
URL API to run a document, and change the value of a drop down selector.
IIS is tinkering with my query parameters though, via a 302 redirect. This URL:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=2048001&src=Main.aspx.2048001&maxWait=-1&documentID=XXX&evt=2048084&src=Main.aspx.oivm.rwb.2048084&ctlKey=XXX&elemList=hXX;XXX&evtorder=2048001%2c2048084&2048084=1&2048001=1
is being 302'ed to:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=2048001%2C2048084&src=Main.aspx.2048001%2CMain.aspx.oivm.rwb.2048084&maxWait=-1&documentID=XXX&ctlKey=XXX&elemList=hXX%3BXXX&evtorder=2048001%2C2048084&2048084=1&2048001=1
(The two distinct evt and src are being combined, and MicroStrategy is complaining that 'Event ID 2048001,2048084 is illegal'.)
Does IIS do this type of thing out of the box? It certainly seems unlikely. I can't see any custom HTTP redirects in IIS Manager for the application.
IIS was most definitely not the culprit.
MicroStrategy was generating the 302 redirect itself, subsequent to an automated login. You would think that an enterprise application wouldn't rewrite its own URL such that it causes an error, but you'd be wrong.
I resolved the issue by manually adding a login event, and URL-encoding the two events I wanted to call into the target key:
https://server/MicroStrategy/asp/Main.aspx?Server=XXX&Project=XXX&evt=3054&src=Main.aspx.3054&target=evt%3D2048001%26src%3DMain.aspx.2048001%26maxWait%3D-1%26documentID%3DXXX%26evt%3D2048084%26src%3DMain.aspx.oivm.rwb.2048084%26ctlKey%3DXXX%26elemList%3DhXX%3BXXX%26evtorder%3D2048001%252c2048084%262048084%3D1%262048001%3D1
Related
We have a requirement to implement a Permissions-Policy to every site hosted on our IIS instance. I have tried to do this by adding a HTTP response header at the server level, but this doesn't seem to get picked up by any of the sites. If I add to each site individually, the policy is applied. I have tried applying directly to the root web.config file but this doesn't work either. What am I missing? We have a large number of sites, so applying to each site separately isn't really an option.
I have an IIS rewrite rule that I'm trying to use.
When I set the Action to ‘redirect’ its working fine. Likewise, if I select Custom response and set some arbitrary status code, I’m getting that back in the HTTP response, so I know the rule is matching for my URL. However, I need to rewrite this (to act as a reverse proxy) but as soon as I change the action to ‘Rewrite’ it doesn’t take effect.
I have installed the Application Request Routing Module and enabled the proxy under ‘Server proxy settings’ (as per this page http://www.iis.net/learn/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing).
I’ve tried everything from restarting the site(s), the server, IIS, the W3p process and nothing takes effect. I've added the rule at a server level as required and confirmed in the ApplicationHost.config file that it is there and correct.
Any ideas what isn't causing this to fire?
I've seen a few similar posts here on SO, but none of them either have a solution or work for me in this instance.
EDIT: OK, so if I change the application pool from integrated to classic, the rule seems to fire (which is weird as the rule is at a server level!?!). However, My site requires integrated mode to function. Anyone know whats going on here?
I would appreciate any hints regarding the following issue:
The problem summary:
While using Negotiate:Kerberos in IIS 7.5, the authorization works correctly right until we setup URL rewriting (using the MS module "URL Rewrite 2.0") - any rewritten URL then returns "401.1 Unathorized" (requests not matching any rewrite rule keep working though).
The setup:
Windows Server 2008 R2 x64
IIS 7.5
URL Rewrite 2.0
Server is in a domain
SPN exists for HOST/hostname and HOST/hostname.domain (created by default)
Pool is using default ApplicationPoolIdentity (no custom account, not network service)
Kernel mode set to OFF
Authentication providers set to "Negotiate:Kerberos" only (no NTLM or annonymous)
URL Rewrite rule as as "^(.*)/$" => "index?x={R1}"
The result:
1) When accessing any URL not matching any URL rewrite pattern, Kerberos is working correctly, i.e. Kerberos ticket is issued (verified using klist), sent (verified using netmon and HTTP headers) and accepted (verified by URL being accessible and appropriate AUTH_USER property set to my domain account name) => no problem here.
2) When accessing any URL matching URL rewrite pattern, e.g. "hostname/foo" the result is:
HTTP Error 401.1 - Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.
Module WindowsAuthenticationModule
Notification AuthenticateRequest
Error Code 0x80070055
Requested URL http://hostname/index?x=foo
Physical Path D:\wwwroot\
Logon Method Not yet determined
Logon User Not yet determined
(if we try to access the rewritten URL directly, e.g. hostname/index?x=foo, Kerberos works again normally)
The attempts to solve it so far:
After googling, we have tried several options:
turning kernel mode ON: Kerberos stopped working completely, using either default pool identity or network service (I suppose we would need to setup additional HTTP SPN and/or use custom domain account with additional SPN for that account explicitly)
turning "useAppPoolCredentials" ON: no difference
enabling "Failing Request Tracing": surprisingly these failing 401.1 requests ARE NOT generating any output into the fail logs no matter what rule we try to setup (e.g. 400-999) - the folder is just empty (while other errors, like 404 or even handshake 401.x when accessing not-rewritten URLs are generating logs - very strange)
The conclusion:
So far we have reached a dead end - it may be some weird kind of "double hop" issue requiring using a custom domain account rather than default app pool identity, but as we're in fact accessing the same resources, it seems more like a URL Rewrite issue.
Any tips, hints, pointers? Anything would be highly appreciated.
Best regards,
Marek
we face the same issues as you do. By enabling extended error logging, we were able to put the finger on the actual problem, which seems to be a bug in the rewrite module (or at least in some part of IIS, which is related to the module):
When the URL gets rewritten, the access to the new rewritten URL is checked (seemingly hardcoded) using Basic Authentication and NTLM, neither of which has been configured on the Website at hand. The only configured authentication provider is Kerberos. Since the client doesnt send NTLM nor Basic credentials, there is no way this can work.
We (another person on the current project) are sending the issue to Microsoft. I will let you know, when I get any result.
It seems as though you have multiple issues here.
Failed-Request Tracing Logs
To fix your missing logs issue, you must make sure that the user that is running your site's AppllicationPool has read/modify rights to the folder where those logs are generated, otherwise you won't see anything. See the section labeled "Enable Failed-Request Tracing" on this page: Troubleshoot Failed Requests Using Tracing in IIS 7
What isn't clear is the fact that the site's Application Pool Identity (found in Advanced Settings for Application Pool) is the account that needs read/modify rights to that folder.
Once that is fixed you can load the XML logs in IE and see a much clearer picture of what is going on.
401.1 - Unauthorized Issue
A possible fix to your 401 error is to make sure unlisted file name extensions are allowed in Request Filtering. Go to IIS --> Sites --> [your site] --> Request Filtering
You have two options here:
Allow File Name Extension... and add the value "." (minus the quotes), see this answer.
Edit Feature Settings... and enabled the option "Allow unlisted file name extensions"
The 1st option should work well, the 2nd option obviously opens up a gaping hole but allows everything so you should be able to get it working.
I hope that helps.
I have an ASP.NET (version 4) MVC 3 application running on IIS 7.5. Anytime there is a single quote in the URL, for example http://devserver.com/myapplication/Home?filter=id~eq~'123' - I get a 403 Forbidden error.
Specifically, this happens when I'm using a Kendo UI grid and am trying to filter one of the columns. But I found that anytime a single quote is in the URL, IIS immediately gives the 403 error.
I've looked in the IIS logs and the event viewer and there is no indication anywhere of a 403 response - I can't seem to find out specifically why the 403 was given.
It's not IIS, it's Siteminder! We have Siteminder in front of our web application, and Siteminder intercepts all incoming traffic for authentication. In this case, Siteminder will also disallow a URL with a single quote in it. Although the 403 error looks like it's coming from IIS, it's really coming from Siteminder.
This issue happened for my app as well and the culprit is Siteminder in my case.
They have a set of BadCSSChars lists which would be validated against our URL. If any bad character is found, the URL will be blocked and wont reach IIS.
Siteminder can remove the 'character needed' exception in the agent.log file (not an expert in this, but heard that this file which stores badcsschars list) in the app server.
Is it possible to manipulate an inbound request at the IIS level, before it even gets assigned to site on the server?
Essentially, I want to rewrite this --
www.somegenericdomain.com?site=someotherdomain
To this --
www.someotherdomain.com
And I need to do this before IIS picks which site the request belongs to, so I need to change the host header prior to this point.
Possible, or crazy? We're running IIS7.
You can rewrite, redirect, or proxy requests.
Rewrite changes the request, but does not change the site to which it is assigned. With a rewrite you can:
return an HTTP error code (503, 404, 401, etc);
manipulate the query string or URL path. one example is to transform a query string param into a URL path element. www.server.com/default.aspx?s=foo becomes www.server.com/foo, or vice versa.
set headers in the request.
Redirect sends back a 301 or 302 response to the browser with an updated address. You can receive a request for www.example.com/foo and respond to the browser with a 302 and an updated address of www.otherdomain.com , etc.
Proxy the request. In this case the web server is said to act as a "transparent proxy". It means the initial IIS server can call out to a second server, grab the response, and then package it up back to the original requester.
These three actions are often done in combination. The tools used to perform these actions are called "URL Rewriters". IIS7 has a built-in option from Microsoft (The IIS URL Rewrite Module), and there are third-party options as well, some free and some commercial, for IIS6, IIS7, and other non-Windows web servers. Apache's mod_proxy is the big one for Linux. All of these tools do basically the same kinds of things.
To answer your specific question, NO, you cannot rewrite a request from one domain to another. For web servers, rewrite is a meaningful term, and a URL Rewrite excludes the possibility of a server change.
It is possible though, to transform a request from one server to another, either via redirect or proxy. One of those may actually be what you want, when you ask about "rewriting" a request.
I guess the whole thing is possible, but not in the way of running before IIS. One part of the server even works as a low-level driver.
But you may use URL rewriting solutions such as mod_rewrite module of Helicon Ape http://www.helicontech.com/ape/doc/mod_rewrite.htm. Having set the software globally for all the sites, you may get what you need as follows:
RewriteEngine on
RewriteCond %{HTTP_HOST} www.somegenericdomain.com [NC]
RewriteProxy (.*) http://www.someotherdomain.com$1