I use a CascadingDropDownList of the AJAXControlToolkit in a ASP.NET MCMS 2002 web application. The CascadingDropDownList works as expected until "Anonymous access" and "Integrated Windows Authentication" flags are both checked (and this is the situation in the production environment) in the Directory Security settings on the website under IIS.
The error I get is:
500 Internal Server Error
No web service found at:
If I uncheck the anonymous access or the windows authentication everything is ok.
Any suggestions?
Modifying:
ServicePath="~/IB20/Services/RegioniProvinceService.asmx"
in:
ServicePath="http:///Services/RegioniProvinceService.asmx"
solved the issue.
It seems that having "Anonymous access" and "Integrated authentication" both checked, brokes the functionality if the ServicePath of the CascadingDropDownList is file-system oriented.
Related
I have a business website that has been running perfectly well on IIS using .NET 4.5, but in Azure it fails.
Now before I lead you too far down this rabbit hole, I can make the IIS fault in the same way as the Azure fault detailed below by NOT converting the website to Application. However, for the life of me I cannot find the equivalent option in Azure; how to convert to Application or equivalent?
I have uploaded to Azure using the Azure App Service Migration Assistant. The only alert was:
"IIS7+ Schema Compliance: One or more elements and/or attributes are being used which are not defined in Azure App Service IIS schema. Consider using XDT transforms."
This links to https://learn.microsoft.com/en-nz/azure/app-service/web-sites-configure which indicates various Azure Application Settings, which I have played with to no avail.
Server Error in '/' Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
Source Error:
An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Source File: D:\home\site\wwwroot\peterfinch\service.desktop\web.config Line: 143
Can anyone please provide any guidance as to what I am missing? many thanks for your time, Peter Finch
so the answer was setting virtual applications and directories for each website, and this now just worked. App Service, Application Settings, at the end of the list, Virtual applictions and directories.
This was the part that was missing, how to 'convert to application'
So resolved it myself, thanks for looking and I hope this helps someone else in the future.
/ site\wwwroot Application x
/mysitename site\wwwroot\mysitename Application
/mysitename/Console site\wwwroot\mysitename\Console\ Application x
/mysitename/Service.App site\wwwroot\mysitename\Service.App\ Application x
/mysitename/Service.Desktop site\wwwroot\mysitename\Service.Desktop Application x
New Windows server 2012 R2 installation, added ASP.Net and .Net 3.5
Getting following error when trying to browse web service file svc:
Could not load type '%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll'.
Any thoughts?
Open command prompt as administrator
Navigate to C:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation
and execute the command:
ServiceModelReg.exe /i
Navigate to c:\windows\Microsoft.NET\Framework\v4.0.30319
and execute the command:
aspnet_regiis -iru
Some roles and features are required on the server
enable server role "Internet Information Services", all underlaying services will be included
enable feature "HTTP Activation", this both under .NET framework 3.5 and .NET framework 4.5
In IIS make sure there is a "handler mappings" configured for the "*.svc" files
That error message turned out to be a bit of a red herring when I encountered it. I simply didn't have a HEAD route setup in WebApiConfig and was getting hundreds of HEAD requests per day. So, if you've verified that you have all the necessary Windows Features installed, then next check that you have default routes setup for each HTTP request method.
Whenever I try to save I get this error (via javascript console)
POST https://domain.local/_vti_bin/client.svc/ProcessQuery 404 (Not Found)
Any ideas?
For me the problem was twofold:
My server was missing the HTTP Activation in WCF Services in the .NET Framework 4.5 Feature.
Go to Server Manager => Manage => Add Roles and Features => Features and make sure it's checked.
I had to add the Negotiate-provider for Windows Authentication in IIS.
Open IIS, go the the site in question, open Authentication, right click Windows Authentication, click Providers..., add Negotiate from Available Providers. I'm having it below NTLM and that works fine.
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.
I have a FinalBuilder project where I deploy an ASP.Net website to a remote folder, configured as a website in IIS.
As part of my build script, I want to use the FinalBuilder action HTTP Get File to help determine whether my deployment was succesful.
I'm having difficulty, because the website is configured (under IIS 6) to use Integrated Windows Authentication, and anonymous access is not enabled.
Now the HTTP Get File action, has only a handful of properties, one of which is a security section, containing a UserName and Password. Great I thought! I can just put some valid credentials in there, which FinalBuilder will impersonate, whilst retrieving my file.
It turns out I was mistaken. I receive the following error:
Error retrieving url : Socket Error # 10061
Connection refused.
If I run the action without setting the Security Username and Password, I get the following error:
Error retrieving url : HTTP/1.1 401 Unauthorized Response Code : 401
Here are some facts to help with the context of my problem.
I'm running FinalBuilder 6 Professional, upon a Windows Server 2003 installation, and deploying my ASP.Net website to a remote IIS6 server within our corporate LAN.
If I configure IIS on the remote server to allow Anonymous access, I can run the HTTP Get File action without error. However, running this particular site with anon access is not acceptable in our situation.
Can anyone help suggest a workaround?
For a definitive answer, I think the Finalbuilder Forum is probably your best bet.
My guess, though, is that the HTTP library used by FB doesn't support Windows authentication, and is failing because no common authentication method can be negotiated. Since HTTPS isn't supported either by the 'HTTP Get File action', the possible workaround of allowing basic authentication on your site isn't a good idea, as you would be passing credentials over the network in plain text.
The only remaining workaround I can think of (other than waiting for a future FB release), is creating your own FB action to retrieve the file. Using the .NET Framework System.Net.WebClient, that should be trivial. Just start with a standalone EXE to make sure everything works, then refactor it into a 'real' action using FinalBuilder Action Studio (if that's even required: spawning an external EXE may work just fine in your case).