I can't seem to get the magic combination of enabling NTLM authentication and still having RDS work. If I leave just anonymous authentication on, RDS works fine - as soon as I enabled it site wide, RDS fails (which is to be expected). Here is what I have done:
This is Windows XP SP2 and ColdFusion 8, Eclipse + Adobe plugins
In the IIS Manager, Right click on default web site and choose Properties
Directory Security tab, click the Edit button for anonymous access and authentication control
Authentication Methods popup window, uncheck anonymous access, and check Integrated Windows authentication (all other checks blank as well).
Click OK, OK, and override the settings for all child sites as well such that the entire site is "secured" using NTLM authentication.
Back in the IIS manager, right click on the CFIDE virtual directory, choose Properties
Directory security tab, edit the authentication methods. Uncheck Integrated Windows authentication and check anonymous access. Hit OK, OK and test:
C:\>wget -S -O - http://localhost/CFIDE/administrator/
--2009-01-21 10:11:59-- http://localhost/CFIDE/administrator/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Wed, 21 Jan 2009 17:12:00 GMT
X-Powered-By: ASP.NET
Set-Cookie: CFID=712;expires=Fri, 14-Jan-2039 17:12:00 GMT;path=/
Set-Cookie: CFTOKEN=17139032;expires=Fri, 14-Jan-2039 17:12:00 GMT;path=/
Set-Cookie: CFAUTHORIZATION_cfadmin=;expires=Mon, 21-Jan-2008 17:12:00 GMT;path=/
Cache-Control: no-cache
Content-Type: text/html; charset=UTF-8
Length: unspecified [text/html]
Saving to: `STDOUT'
... html output follows ...
And so far so good, the CFIDE directory and at least one child directory appear to be working without NTLM authentication. So I fire up Eclipse and try to establish an RDS connection. Unfortunately I just get an Access Denied message. Investigating a bit further it appears that Eclipse is trying to communicate with /CFIDE/main/ide.cfm - fair enough, pull out trusty wget once again see what IIS is doing:
C:\>wget -S -O - http://localhost/CFIDE/main/ide.cfm
--2009-01-21 10:16:56-- http://localhost/CFIDE/main/ide.cfm
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Wed, 21 Jan 2009 17:16:56 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Content-Length: 4431
Content-Type: text/html
Authorization failed.
One potential hang up that has been documented elsewhere is that the main directory and ide.cfm page don't actually exist on disk. IIS is configured to hand off all .cfm files to JRun and JRun is configured to map ide.cfm to the RDS servlet. In an attempt to force IIS to be a bit more sensible, I dropped a main directory and empty ide.cfm file on disk hoping it would solve the authentication issue but it didn't make any difference.
What I can do as a work around is leave the entire site as anonymous access and then just enable the specific application folders to use NTLM integrated authentication, but there are quite literally hundreds of possible web applications I would have to do that for. Yuck.
Please Help!!!
There is something strange about answering your own question, but I did finally get it resolved.
NTLM integrated authentication can be enabled for the entire web site
Anonymous access must be enabled for the CFIDE virtual directory
Anonymous access must be enabled for the JRunScripts virtual directory
Once both CFIDE and JRunScripts had anonymous access enabled, RDS and debugging through Eclipse worked like a charm.
Related
I configured a Frontdoor on Azure, with 2 rules
(HTTP endpoint) Rewrite HTTP to HTTPS
(HTTPS endpoint) HTTPS to backend pool
When requesting the http endpoint Frontdoor answer this:
HTTP/1.1 302 Found
Location: https://example.com/
Server: Microsoft-IIS/10.0 <------
X-Azure-Ref: xxxxxxxx
Date: Wed, 08 Jul 2020 12:00:00 GMT
Content-Length: 0
Is it possible to remove this header ? I know it's a managed resource but I can't find any documentation on this matter/if it's normal.
I don't believe it's my backend answering because my https endpoint doesn't answer me that ... but maybe?
You can set Rules engine configuration in Front Door.
The server information may not be displayed at present due to my environment. But you can still refer to my screenshots for configuration.
I found that the information such as Date, although I modified it, still does not take effect. It may be related to the information returned by the azure server and cannot be modified. You can try to modify the Server information.
After the modification, if the Server information remains unchanged, there is no way to modify it.
Related similar posts you can refer to:
ASP.NET MVC 5 Azure App ZAP Scan indicates Proxy Disclosure vulnerability - how can we prevent that?
In the webapp, no matter the program is modified or in other ways, the server information cannot be modified.
So if the above method can be modified successfully, it can be of great help to you.
If it doesn't work, you don't have to spend time to deal with this problem. You can raise a ticket in portal to confirm.
I've got 6 identical machines running IIS and Apache. Today one of them decided to just stop serving requests. I can access all of the webapps when I try from localhost/resource but when I try from url/resource I get a 404. I did a Get request against the machine that isn't working and I get this back:
Server: Microsoft-HTTPAPI/2.0
Connection: close
Compared to a working server:
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Content-Type: text/html
Tried searching for this problem but came up with nothing, anyone got any idea's?
Windows has an HTTP service that manages calls to IIS and other HTTP enabled services on a windows machine. Either you need to configure it to handle your calls, or, in the case of WAMP or similar non-IIS-web-server-on-windows scenarios you may just need to turn it off.
When you see "Microsoft-HttpApi/2.0" returning error, such as 400 "bad URL" or "bad header", etc. the problem is most likely because the HTTP.sys service is intercepting your http request and terminating it because it does not meet with the minimum validation rules that are configured.
This configuration is found in the registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. In my case, it was choking because I had a RESTful call that had a 400 character segment in the url which was 160 characters more than the default value of 260, so I
added the registry parameter UrlSegmentMaxLength with a DWORD value of 512,
stopped the service using net stop http
started the service using net start http
I've run into these issues before and it is easy to troubleshoot but there is very little on the web that addresses it.
Try these links
"the underlying problem is that the client has sent a request to IIS that breaks one or more rules that HTTP.sys is enforcing"
enabling logging on HTTP.sys is described here
a list of the HTTP.sys parameters that you can control in the registry is found here.
A bit late, so put here for posterity ;-)
After trying all sorts of solutions found on the web, I almost gave up, but found this little nugget.
If the response's Server header returns Microsoft-HttpApi/2.0, it means that the HTTP.sys is being called, not IIS.
As a result, a lot of the workarounds will not work (URLScan, etc).
This worked however:
Open regedit
Navigate HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\
If DisableServerHeader doesn't exist, create it (DWORD 32bit) and give it a value of 2. If it does exist, and the value isn't 2, set it to 2.
Finally, restart the service by calling net stop http then net start http
src: WS/WCF: Remove Server Header
Set below registry flag to: 2
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader
Setting this to 2 will ensure that self host WCF services no longer sends the SERVER header and thus ensure we are security compliant.
Please note that this disables ALL server headers.
The default value of 0 enables the header, and the value of 1 disables server header from DRIVER (http.sys), but app can still have headers.
For me I had to restart the server for the changes to take effect.
Hope this helps someone
I was working on our web app on a client's site and ran into an issue where the site root pages loaded, but the reports folder always returned a 404 for files that existed in the folder. The 404 page showed the .Net version of 2 when the application was set to 4, and a test of a non-existent page in the root returned a 404 page showing .Net 4.
I tried just http://localhost/reports and got back a Microsoft Reporting Services page. Not part of my application.
Be sure to check just the default document of the folder when a unexpected 404 comes up and the file exists.
This question and series of replies helped me get to the bottom of the related issue I was having. My issue centered around using just a subdomain to go to our server (e.g. typing "www/somepath" into the browser while on our corporate network), which had worked in the past on an older server, but no longer worked when the system was upgraded to a new server. I saw the unexpected Microsoft-HttpApi/2.0 string in the header when using the Chrome Devtools to inspect the Network traffic.
My HTTP.sys process was already logging, so I could verify that my traffic was going to that service and returning 404 NotFound status codes.
My resolution was to add a binding to the IIS site for the subdomain, making IIS respond instead of the HTTP.sys process, as described in this server fault article - https://serverfault.com/questions/479274/why-is-microsoft-httpapi-returning-404-to-my-network-switch
In my case, running Windows 10 Pro, it was the Windows MultiPoint Service.
By executing:
net stop wms
Port 80 was released.
I have a classic ASP website that posts a form to a page that then generates and streams an Excel file out to users. Actually, its a raw HTML table which I send with:
Response.AddHeader "Content-Disposition", "inline; filename=file.xls"
Response.AddHeader "Content-Type", "application/vnd.ms-excel"
The intranet website is secured via integrated windows authentication. No other access mode is checked. The user logs in with their network password and all is well.
Now, when the user submits the form, this action results in two more login dialogs. You can actually cancel out of both and still open the file. In fact, if you put in your credentials, it requires you to enter them four times! If you check "Remember password", it doesn't affect the need for logging in. Also, this happens even if the URLs are listed on the Trusted Sites section of IE.
Any ideas on what I can do to minimize this?
PS: Not sure, but seems to be a relatively recent issue, meaning a more recent version of IE (7/8), Office (2007+) and or Windows (Vista/7).
UPDATE: Using Fiddler, I can see that something called "User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7600" is attempting to connect, and getting 401.2'ed. Is IE offloading the download to something else that isn't authenticating properly?
UPDATE2: Doubly-interestingly, Firefox does none of this. It receives and interprets things properly:
HTTP/1.1 200 OK
Date: Mon, 21 Feb 2011 19:25:26 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Disposition: inline; filename="SavingsReport_4Q2010.xls"
Content-Type: application/vnd.ms-excel
Content-Length: 111851
Cache-control: private
Old question but here goes in case someone else stumbles on it.
Office tries to authenticate with the file server, through an OPTIONS request, in order to access the file as explained on this article.
Without entirely understanding why, changing your content-disposition from inline to attachment will not prompt for authentication in most environments.
Be careful as this seems to have an effect on the file's name (on win XP - IE7.
E.g. file with name file name.xls would be opened as file_name.xls
Here is example classic ASP Code:
Response.AddHeader "Content-Disposition", "attachment; filename=MyReport.xls"
I'm trying to implement a page that allows Excel users to use the data it provides via the Web Query feature provided by Excel.
It's all working out pretty nicely, as long as I use HTTP (even BASIC user authentication works).
As soon as I switch that over to HTTPS Excel won't download the data anymore (it's even a fully official SSL certificate, so it's not a problem with a self-signed one).
This Microsoft knowledge base article pretty much describes the problem.
Now the part that makes me wonder is this:
This issue occurs when Excel cannot initiate a connection because of the settings on the secure Web server.
This seems to imply that there is some way to get this working, but there's not even a hint at the direction I need to look at.
Should the "because of the settings on the secure Web server" be taken at face value, or is it just a Microsoft way of saying "this won't work unless you buy the right software from us"?
It seems I've found the problem:
MS Excel seems to be unable to use the data on the page if the HTTP headers of the page specify that it should not be cache and it is transfered via HTTPS (the same headers sent via HTTP seem to get ignored).
So by not sending these headers, Excel was suddenly able to access the data:
Pragma: no-cache
Cache-Control: no-cache
Joachim's answer solved the problem for me. The server-side web framework (PHP5 / Expression Engine 1.6.7) was sending a Pragma: no-cache on every request (even though my web-query results page set Pragma: public, I guess the framework overrode it). Once I removed it, everything started working.
IE and Office behavior for Pragma: no-cache is similar to that described in MS KB Article: Internet Explorer is unable to open Office documents from an SSL Web site
See also this caching tutorial's Warning: Pragma no-cache Deprecated. With this in mind I set Expression Engine' Output and Debugging > Generate HTTP Page Headers? option to No. (Other frameworks have similar config options). But some of the other automatically sent headers were needed for successfully caching the rest of the site, so I opted for commenting out the Pragma: no-cache lines in the framework source code.
If you do not have the option of modifying the HTTP headers sent by your web server / framework, the only MS-Office-client-side-only option will be to use VBA macros to automate an Internet Explorer component to get around Office's caching behavior. See Different Ways of Using Web Queries in Microsoft Office Excel 2003 as a starting point.
We have a problem with an IIS5 server.
When certain users/browsers click to download .zip files, binary gibberish text sometimes renders in the browser window. The desired behavior is for the file to either download or open with the associated zip application.
Initially, we suspected that the wrong content-type header was set on the file. The IIS tech confirmed that .zip files were being served by IIS with the mime-type "application/x-zip-compressed".
However, an inspection of the HTTP packets using Wireshark reveals that requests for zip files return two Content-Type headers.
Content-Type: text/html;
charset=UTF-8
Content-Type:
application/x-zip-compressed
Any idea why IIS is sending two content-type headers? This doesn't happen for regular HTML or images files. It does happen with ZIP and PDF.
Is there a particular place we can ask the IIS tech to look? Or is there a configuration file we can examine?
I believe - and i may be wrong that the http 1.1 header sends multiple headers definitions and the most specific has precedence .
so in your example here it is sending 2 text/html and then application/x-zip-commercial so the second one would be the most specific - if that cant be handled on the client then the more general one is used (the first one in this case ) -
I have read through this http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and that sort of points to what you are saying - not sure if this is what is actually happening though.
Of course i may be totally wrong here
Make sure that you don't have any ISAPI filters or ASP.net HTTP modules set up to rewrite the headers. If they don't check to see if the header already exists, it will be appended rather than replaced. We had issues a while ago with an in-house authentication module not correctly updating the headers so we were getting two Authorization headers, one from IIS and one from our module.
What software has been installed on the server to work with .zip files?
It looks like IIS picks up MIME translations from the registry, perhaps zip-software you use has registered the MIME-type. This doesn't explain why IIS would respond with two content-type headers, so any ISAPI filter and other Mime-table is suspect.
This may be related to this knowledge base article. It is suggesting that IIS may be gzipping the already zipped file, but some browsers just buck pass straight to a secondary application giving you bad data (as it has been zipped twice). If you change the mime type of the zip extension to application/octet-stream this may not happen.
It sounds like there may be a issue with your configuration of IIS. However that is not possible to tell from your post if this is the case.
You can have mime types configured on several levels on your IIS. My IIS 5 knowledge is a bit rusty, as far as I can remeber this behavior is the same for IIS 6. I tried to simulate this on a IIS 6 enviroment, but only ever received one mime type depending on the accepted header
I have set the the header for zip files on the site to application/x-zip-compressed and for the file I have explicity set it to
tinyget -srv:dev.24.com -uri:/helloworld.zip -tbLoadSecurity
WWWConnect::Connect("server.domain.com","80")
IP = "127.0.0.1:80"
source port: 1581
REQUEST: **************
GET /helloworld.zip HTTP/1.1
Host: server.domain.com
Accept: */*
RESPONSE: **************
HTTP/1.1 200 OK
Content-Length: 155
Content-Type: text/html
Last-Modified: Wed, 29 Apr 2009 08:43:10 GMT
Accept-Ranges: bytes
ETag: "747da786a6c8c91:0"
Server: Microsoft-IIS/6.0
Date: Wed, 29 Apr 2009 10:47:10 GMT
PK??
? ? ? helloworld.txthello worldPK??ΒΆ
? ? ? ? helloworld.txtPK?? ? ? < 7 ? hello world sample
WWWConnect::Close("server.domain.com","80")
closed source port: 1581
However I dont feel this prove much. It does however raise a few questions:
What is all the mime maps that have been setup on the server (ask the server admin for the metabase.xml file, and then you can make sure he has not missed some setting)
Is those clients on a network that is under your control? Probably not, I wonder what proxy server might be sitting inbetween your server and the clients
How does the IIS log's look like, for that request, I am spesifically intrested in the Accept header.
I wonder what fiddler will show?
I've encountered a similar problem. I was testing downloads on IIS 6 and couldn't figure out why a zipped file called test.zip was displaying as text in IE8 (it was fine in other browsers, where it would download).
Then I realised that for the test I'd compressed a very small text file. My guess is that IE sniffed the file, saw the text (which was pretty much uncompressed because of the small size) and decided it was plain text.
I tried again with a larger file and the download prompt appeared OK in IE8.
May not be relevant to your case, but thought I'd mention it.
Tim