clientaccesspolicy.xml suddenly stopped working (WCF/Silverlight) - wcf

Very frustrated with all of this, hoping someone can assist.
I had a Silverlight application and WCF working together without issue for a year. In order to get them working, I had some pain initially but finally worked through it with help. All of the pain came from configuration/security, 401's, cross-domain hell, etc.
The way I have everything setup is that I have a WCF service that resides in it's own application/directory and runs in its own application pool.
On the same web server (IIS7), I have another application/directory with the Silverlight application that points to the aforementioned service.
The server name (for this exercise) is WEBSERVER1. We've created a CNAME for it that is WEB1. In the past, if the user went to http://WEB1/MyApp/ or http://WEBSERVER1/MyApp/ it would work. Suddenly yesterday it started behaving badly. Normal users started getting the Windows challenge/response prompt (and even if they entered the info they would get a 401 error).
My WCF service runs in a site that enables anonymous access (and this has always worked).
My Silverlight application runs in a site that has windows integrated (and this has always worked), since I capture the Windows username when they connect.
For the record, I did create a NEW application pool yesterday with an ASP.NET application that runs in it. This seems to work fine, but there is a chance creating this new application pool and application/directory has caused something to change.
I have a clientaccesspolicy.xml in my wwwroot folder, as well as in the folder for each of the two applications above (just in case). I have tried to promote NTLM over Negotiate as a provider (as that worked for another issue I was having on another server).
After trying some changes, I can't even get the thing to behave the same each time I call it. Sometimes it will prompt me for credentials. Other times it will work, but then say it failed to connect with the WCF service with a "not found". Other times it will actually work fine, but only if I am using the actual server name and not the CNAME. When using the CNAME I always get the crossdomain error, even though I have the cross-domain xml files in every directory root.
This is a nightmare, and makes advanced algorithm analysis seem fun and easy by comparison. Did Microsoft realize how difficult they made this combination of (IIS7/WCF/Silverlight/providers/permissions/cryptic or missing error messages) to get to work??

I found a solution that appears to be working.
In this case, I had to change the authentication mode for the default web site (which hosted the clientaccesspolicy.xml file) from anonymous access to Windows Integrated. I don't understand why this worked for a year or so and then stopped, but it seems to have resolved it.
The new application that I had deployed yesterday was a standard ASP.NET web application, which I put in it's own application directory and it's own application pool, to ensure that it would not cause this sort of issue. I'm still not even sure if it did.
The way I resolved it was by trying to navigate from my PC to the actual http://servername/clientaccesspolicy.xml file, and that was giving me a 401 error. I switched from anonymous to windows integrated on that default website (which has nothing in it except for that xml file) and that resolved the permission issue. I then had to permission the actual AD groups to have read access to that folder (if not they got the user/pw prompt and could not get through).

Related

Why is transfer from test to production of Asp.Net-Core app completely not working

We've been finalizing NopCommerce .Net Core web app which has been running great on a test server. I'm now trying to transfer the app to our production server, which did not have .Net Core. I installed the latest .Net Core hosting bundle and rebooted the server. I also have Web Deploy running on both the host and the client. I exported the app from the test machine and imported it into a newly created IIS site. After setting up the bindings - and enabling stdoutlogging, I try to see what's working, and get indication that "An error occurred while starting the application". No indication what the error is. Logs is not being written to. The event viewer tells me that:
Application 'MACHINE/WEBROOT/APPHOST/NOPCOMMERCE' started process '6980' successfully and is listening on port '41573', which is a random port not binded to.
One interesting thing I noticed on the test server is a "user" called nopCommerce which has full rights to the nopCommerce folder in inetpub/wwwroot. However this user does not show when I look at local users and groups. I am not sure therefore what this "user" is and if/how I should create it. Based on some advice from somewhere I temporarily gave everyone full rights to the nopCommerce folder, but that didn't work either.
Can anybody please aim me in the right direction?
Problem was a bad setup - access rights to subfolders of nopCommerce was one, which I solved by giving the users group modify rights. This might be a bad idea and I will do some more research. The other fault was a bad database login in the connectionString.
Ultimately I had to learn that instead of starting the app via IIS, it can be run from the command-line, and then messages and errors will be displayed in the DOS box. What to run is determined from the
I still don't know where the nopCommerce user comes from on the staging server.

IIS 8.5 on Server 2012 R2 stops responding after a time

I recently updated a server from 2008 R2 to 2012 R2 that hosts a few MVC sites and a Web API. After deployment, everything seems to work fine for a few days before the web api seems to fail. It returns a 404 for all requests to the API from the failure forward. The parent MVC site seems to continue working fine.
A few things:
The web api is hosted as a web application inside a parent website within iis.
This is a 4.6.2 framework site and api.
I would prefer it to be its own site but I don't control this.
It seems to stop at roughly the same time when it occurs - around 2:35 AM
The only route defined by the web api is a GET
I've checked the event log as well as IIS logs. The event log doesn't reflect anything during these times and the IIS logs just show a 404 response. Resetting IIS/AppPools/etc... don't fix the api nor does restarting the machine. In fact, the only thing that seems to fix it temporarily is a VS publish over top of site.
I suspect something to do with MSDeploy but have nothing concrete. Does anyone have any ideas on where to look or what to look for? I feel it must be something to do with the server configuration as we've never seen this problem prior.
I ended up finding out the problem. Our project uses NLog with the config specified to create a new log file daily. Something within either NLog or IIS recently decided not to play nicely together. A temporary fix was to turn off the daily file creation from within NLog. Since making this change, the site has stayed up consistently for the past week.
This post is what got me checking into NLog as a possible culprit.

Inherited a Silverlight/WCF application need to fix WindowsAuthentication

I've inherited a Silverlight/WCF application. (Having worked on .net MVC, and SPA for quite a while)
I tried switching the IIS website folder to see if a tweak to the code and a fresh build would work, it didn't work and I switched back and although the website is functional it has a number of faults.
For some reason the Windows authentication appears to have stopped working, this authorises a number of the admin functions. I think this is broken and so not enabling the functionality in the Silverlight app.
The server I've inherited has the applications as folders in the default website, which is new to me, and quite constraining. I've gone through IISAdmin videos, and learnt a lot, but not enough to fix the issue.
I am unable to get the software to run in VS2013, quite a bump after working on Single Page Applications.
I'm stumped as to how the same code put back no longer works; I've learnt my lesson, but I still need to fix the system. I am not sure whether IISReset would make a difference since the AppPool is recycled every 29 hours. I've found out what the harm in trying is, and so I am proceeding with caution.
So my main goal would be to get the Windows Authentication working again.

WCF, DLLIMPORT strange issues

I have a very strange issue that i cannot figure out.
First i have a WCF service 4.0 done in VS2010.
the service have couple methods that return string array, datatable and such.
some of them use function from C++ dll throught [dllimport]
i made a test console to test everything. when i run the WCF from visual studio and use the generated path it works wonderfully.
now here is where it become strange. if i open my local IIS create a new application and point to my VS source code the WCF i can see it perfectly.
now using the http path from IIS local instead i refresh the methods all seems correct. But when i run my test app i can call any unction without any problem EXCEPT anyone using DLLIMPORT functions. they ALL crash and cannot trace even by tracing CES exceptions.
Doing line by line logging show that the exception is really on the call of those functions
the DLL in question is the same and the path is hardcoded for my computer since still in test phase and the folder is c:\DLL\mylib.DLL so nothing to do with shadow copy IIS/visual studio do when you actually run. also DLL reference by name withotu path even if it's in sys32 doesnt work.
Any clue ?
also. 32bit, changing app pool level right access on folder, full admin on machine already too. all tried but unsuccessful.
Edit: adding to all that since i haven't made this clear, it's not my first WCF real setup. i've already made alot of services before and deployed them myself (probably somewhere around 50-60 services). I am asking because i have never seen this issue before and i tried all tricks i knew and could find on the internet and resource people i know.
We have decided to incorporate the whole service in the WPF project locally since it work as long as IIS is not hosting. but this is really not a good thing as this data and work should NOT be done on client side but instead on server side. Right now it's fine since the software that need to use this is not released to public yet so it isn't critical.
Next option will be net TCP/IP windows service hosted on the web server if i don't find anything else.
We decided to go trough the trouble of having to hard code the logic in the main software and get away from web services for this issue. we will have to deal with updating, installing unregister and re register unmanaged DLL by hand somehow but at least it works.
we have added over 5 web services since that happen and no problem with them but again none of them use DLL imports.

IIS7 (Windows) Authentication -- Cannot figure out why new website errors 401

I am trying to make a new website on an IIS server, of which has websites that are using Windows Authentication just fine. However, for the life of me, I cannot figure out why my new website refuses access (401.2)
Basically, I create a new website and add a single .html file ("Hello, World"). I can access it just fine. But turn off Anonymous, leaving on Windows Authentication, I get prompted for ID/PWD, ending always a 401.2
So, I decided to make a new website as a copy of the existing working website on the same webserver. I've even gone and made the new website share the same App Pool and the same Physical Path. This way, as far as I can tell, the only possible differences between the two websites is now the IIS configuration of the two sites. Still can't authenticate.
I've switched the bindings, doesn't help.
I've even compared the settings in applicationHost.config, making sure they're equal.
Any ideas? Thanks in advance.
I've used this article several times for problems like these with some success: http://blogs.msdn.com/b/david.wang/archive/2005/07/14/howto-diagnose-iis-401-access-denied.aspx Hope it helps!
I was advised to try running iisreset from the command line. This turns out to be what I needed all along. Seems some configuration changes do not get applied properly, even when restarting the particular website, until IIS itself is restarted.