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.
Related
I have Shibboleth configured on an IIS server and am using it protect a .NET application.
I need authenticated access for users accessing the application over the web and for that Shibboleth is working fine.
The application also hosts web services which need to be accessed by other applications in the same server and for that working with Shibboleth is a challenge since web service clients cannot deal with the log in page.
Is it possible to configure Shibboleth to ignore requests coming from the same server for example by checking the IP address?
It won't directly answer your question, but I can share a workaround I found and hope it can help with your problem too.
Define another website in IIS pointing to the same folder as the initial one, and make it only respond to a different domain (like something.local). Then in IP Address and Domain Restrictions, make sure only 127.0.0.1 is allowed to access it.
In C:\Windows\System32\drivers\etc open the file "hosts" in Notepad (running with Administrator privileges). Add the line "127.0.0.1 something.local" (no quotes; make sure the domain is the same one you defined before)
Now, make the webservices call the application by the new domain.
Well. I created reference, tested on local machine all is well. Deployed solution to production server and here we go:
An error occurred while trying to make a request to URI
This could be due to attempting to access a service in a cross-domain
way without a proper cross-domain policy in place, or a po
From what I gathered - it's security measure to prevent something (not sure what). Well. I can't make provider to put clientaccesspolicy.xml and crossdomain.xml.
What is my options? Looks like either running Silverlight app in elevated mode or.. ?
I don't want to require elevated trust.
The only way I know is to call my server and make call to webservice from my server returning data back to client. Seems like too much overhead. Is there any better way? Really frustrating.
I'm afraid your options are limited here. In compliance with Same Origin Policy the cross domain policy file is a must. Here you can find an example why. Personally I would go down the route of proxying the remote web service via your hosting server if you can't influence the provider.
We use NTLM auth to access an ASP.net web services from our MonoTouch app and everything works fine.
One of our customers uses the same app and the NTLM auth fails from our app but works from the iPad's Safari browser.
Looking at the packet flow from the customer, the server does not return NTLMSSP_CHALLENGE, when our app sends NTLMSSP_NEGOTIATE message.
Looking the differences between our app's NTLMSSP_NEGOTIATE message and iPad's Safari same message
Our MT app sets the NTLM flags to 0xb203 and Safari sets this to 0x88207.
The NegotiateNtlm2Key is set to 0 in our app and 1 in Safari
Our app also sends the calling workstation domain and name fields whereas Safari send both as null.
The client's server is Windows Server 2003 and they also use Kerberos as their main authentication scheme and fall back on NTLM.
Would setting the NegotiateNtlm2Key flags in Mono.Security.Protocol.Ntlm.NtlmFlags help?
NTLMv2 Session and NTLMv2 Authentication has now been implemented in Mono (mono/master commit 45745e5).
See this article for a description of the different NTLM versions.
By default, Mono now uses NTLMv2 Session Authentication whenever the server supports it and falls back to LM & NTLM otherwise.
The default behavior can be configured by using the new Mono.Security.Protocol.Ntlm.Type3Message.DefaultAuthLevel property in Mono.Security.dll (see Type3Message.cs and NtlmAuthLevel.cs in mcs/class/Mono.Security/Mono.Security.Protocol.Ntlm).
This is similar to the Lan Manager Authentication Level in Windows.
Update 01/26/13
There has been an issue with Microsoft Server 2008 RC2 not accepting the domain name that it sent back in the Type 2 Message's Target Name (or Domain Name from the Target Info block).
Therefore, we are now using the domain name from the NetworkCredential to allow the user to specify the desired domain. This is also the domain name that's initially being sent to the server in the Type 1 Message.
Simply setting flags ? Maybe but IMHO that's quite unlikely.
That code base was written in 2003 (and updated in 2004) and I'm pretty sure that I (as the author of the low-level code) did not have access to a Windows 2003 server or a Kerberos-enabled domain at that time.
The amount of required change, for a fallback, might not be too large (but I would not bet 5$ on that ;-) if you already have the environment to test it. I'm 100% positive that the Mono project would be happy to receive patches to enable this. You can also fill a bug report (priority enhancement) to ask for this feature at http://bugzilla.xamarin.com
An alternative is to use the iOS API, which I assume Safari is using, to communicate with the ASP.NET web service and deserialize the data yourself. Hard to say which options is more complex.
Now I want to prefix this with I am unsure whether this should be here or on server fault so I'll post it here to begin with.
We are developing a REST API in Coldfusion 9 which is being hosted on IIS 7 for a client which on certain calls must call another internal webservice. When making these calls from the server that the API is hosted on there are no errors, however when we make the call from a remote machine the following message is returned:
'connection failure. status code unavailable.'
I have googled the issue where the following was suggested as a fix http://www.talkingtree.com/blog/index.cfm/2004/7/28/20040729 but it does not work for me. The following are the notes from my own testing:
The calls which are causing the issue are a mix of get, put, post and delete.
The only common part of each call is the talking to the same webservice.
I am able to call the webservice directly from the places where I make the remote calls to the API from.
While all the calls make a call to the same webservice they do not all make the same call to the webservice.
Ideas:
Call the web service remotely using a URL that resolves to the internal ColdFusion server (e.g. http://[servername]:8300). You will probably have to some configuration to get this working. Reason for doing so is to identify if IIS or ColdFusion is the root cause. If you can hit the internal server remotely then IIS is probably the issue.
Is the web service call over SSL? If so, is remote caller also ColdFusion? If you've answered both yes, check to see if the SSL certificate is trusted by the remote caller's JVM. If not, you need to register it as part of the JVM's keystore.
Can you ping the host server from the caller? If not, does the caller need a "hosts" entry?
If enabled on your host, review the .NET filter and how it interacts with HTTP calls. I've experienced a situation where I was unable to access a folder called "/bin" because the .NET filter intercepted the requests.
The issue turned out to be that each of the calls required basic authentication which the calls themselves were handling, however basic authentication had been turned on in IIS which was causing IIS to intercept any requests with an Authorization header.
This causes an issue as IIS assumes that if authentication is passed up then it is for a user on that machine/domain and would reject any other credentials (which were valid for the system). It was working when we were logged into the machine because it was coming locally it did not need to authenticate the user.
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).