I have an existing VS2010 ASP.NET webforms site that I am trying to get running on Azure as a POC for a client.
I migrated the site to a VS2012 project, added an Azure Cloud Service Project, and have deployed the site as well as the back end DB to a 3 month trial account.
I've added the IP address of my dev machine to the firewall rules for the Azure db, and I can run the project locally and connect to the Azure db without incident.
On the firewall rules for the website, I have Windows Azure Services set to yes under Allowed services. I have no other rules in place other than the one for my dev machine.
When trying to access the site from the site deployed to Azure, I get the following exception:
Cannot open server requested by the login. Client with IP address '137.135.65.13' is not allowed to access the server.
To enable access, use the SQL Azure Portal or run sp_set_firewall_rule
on the master database to create a firewall rule for this IP address
or address range. It may take up to five minutes for this change to
take effect.
Login failed for user .
This session has been assigned a tracing ID of . Provide this tracing ID to customer support when you need assistance.
The site works normally if I add a firewall rule for the azure server IP address, but doesn't this defeat the whole purpose of Azure? Shouldn't allowing Azure services handle this? Is there an additional config item necessary or am I missing something basic in the design? I'm not sure if this is related but the site was deployed by VS2012 as a cloud service instead of a website, is this the issue? I also added the db as a linked resource in the cloud service but that didn't seem to have any effect.
Adding the DB as a linked resource for the WebSite will fix the problem w/out having to muck about with firewall settings.
Go to your website in m.anage.windowsazure.com.
Go to the LINKED RESOURCES tab.
Press the LINK button on the bottom of the page
Select your DB from the modal dialog
This is a bug in Azure. Newer IP ranges aren't included in their boiler plate "Azure Services" configuration, or something like that.
Been happening for a long time (at least ~3 years), unfortunately.
Happens with Web Roles, Worker Roles, and VMs as well - NOT specific to Web Sites. We regularly hit this with our Web and Worker Roles in US East but never saw it once in US North.
Our work-around is to add the range: 10.0.0.0-10.255.255.255. Probably not the most secure work-around but fortunately, this has so far only hit our Dev environments and not any of our Production environments.
Related
We recently had to change a domain admin password due to a security issue. As a result, on our prod web server, we're seeing a large number of Event ID 4625 errors showing up in our security log associated with an IIS App Pool. We're on Windows 2012 R2/IIS 8.5; ASP.NET 2.0 & 4.0 are installed on the system.
The interesting piece is that the App Pool in question never used the domain admin account as its Identity. It has always used the out of the box ApplicationPoolIdentity. I should also note that the server was logged off using that affected user well prior to the password change & a new account is now used to administer the server.
The server itself though was in fact built using the affected domain admin account. All roles/features were added while logged in as the aforementioned account. With this in mind, no services are running as the account, ie World Wide Web Publishing Service/IIS Admin service. They're running as Local System & always have.
No functionality has been compromised, everything is operating normally on the web server. The issue is that our tech services team is receiving constant notifications from their account monitoring software regarding the bad logon attempts & it is impeding their operations. Full disclosure... We haven't had an opportunity to reboot the server yet since its production, we will be doing that tonight.
The problem seems to be relegated to the root of the site, the \wwwroot folder. Segregating only the root app to its own app pool/turning off the pool is not an option since it services file system requests. We've tried explicitly setting the identity on the affected app pool to use Local Service as well as a regular domain user. The issue persists regardless:
So naturally, our hope is that the reboot takes care of it... Perhaps the old password is stuck in a kerberos cache, but it's just strange since this app pool never used the ID as its identity, that it continues to show up.
We had a virtual directory that was using the ID in order to reach out to a CIFS share on the network. Once we changed that, the error ceased.
I deployed my MVC 4 application on Azure, installed own CA, create self-signed certificate and certificate for server (https working good). How can I activate require client certificates signed by my CA and working only with it?
The two viable options you have, you already described in your comments.
One is to use Azure VM and IIS (I don't like it) - there you know what to do.
The other one is to use a Web Role (Cloud Service) and do the things described in the link you refer to. I advise you to take the Web Role path.
Or third option, is to wait until (if ever) Windows Azure Web Sites to unlock the required property in application host config. Check this SO question and it's answer on what you need to do in your web.config in order to achieve your goal. The catch is that access section under system.webServer/security is locked at application host config level, and can only be unlocked when you have Azure Web Role.
Just fyi, here is a list of overridable sections in your web.config when you use Azure Web Sites.
I am using Elmah in one of our production deployments and would like to secure the module to the local network only and not expose it to the public. I am aware of the remote logging option that can be turned off and also asp.net authorization, however I am interested to know if there is any support in Elmah's configuration to bind to a secondary NIC/network card which only faces the internal network ?
There's nothing built-in Elmah that will allow you to achieve this but here's what you might do: disable elmah.axd on your public site and configure it to write errors to some data source (a file, SQLite database or even SQL server). Then configure an intranet site which will have elmah.axd enabled and will point to the same data source used by your public internet site. This way you could use the intranet site to see the errors. If you have a web server farm and multiple applications you could use a centralized SQL Server database which will store the application name as an additional column so that when you navigate to the intranet elmah.axd you will have a complete overview of the errors occurring on your public production servers.
I have been tasked with getting a asp.net (vb.net) talking to an analysis services engine on our production servers. The web server is a separate machine from the web server. The web server runs as the IUSR_ user. The application (of course) works on the development machine which has both IIS and Analysis services on it. The problem I see appears to be a permissions error (returned in the browser by the asp.net app):
An existing connection was forcibly closed by the remote host ....
it is described in a similar post here: http://www.mydatabasesupport.com/forums/sqlserver-olap/201903-existing-connection-forcibly-closed-remote-host.html
I am not a system admin, nor am I an expert in analysis services (why have I been tasked with this you ask? because other people haven't been able to get it working and it has fallen on me). Anyway, I could use some help ... I have tried creating and adding the user (IUSR_) to the sql server and added that user to the role. While that worked on my local machine, it did not work in our production environment where the sql and web servers are separate.
tia,
Don
well after some fiddling i came up with something that works. its probably not a huge security concern because this server is not visible to the public internet; it is visible only to a couple iis servers (it is not on our lan) - this is, however, a 'brute-force', non-secure solution (in some environments anyway) ...
ON THE IIS SERVER: added this to the connection string in web config: SSPI=anonymous; this turns on an unauthenticated access request.
ON THE SQL SERVER: in analysis services, right click on the server. under "general" go near the bottom to "Security\RequireClientAuthentication" and change it to False
same page, select "security" on the left (instead of general). Add "ANONYMOUS LOGIN" to the list of users
get out of the server properties. right click on the CubeViewer role in the cube and choose properties. Add ANONYMOUS LOGIN to the list of users.
so, i have unauthenticated access from our iis server to the sql server.
i'd still be interested in seeing a more secure solution - oh, and i forgot to mention, there is no domain ... these are two servers on the same subnet with only regular logins.
Best practice says to keep my web app and database on separate machines, but when doing that it seems I can't get a clear explanation on how best to make this connection. Whil windows auth is the recommended authentication, I don't see how to make a trusted connection . Must I use impersonation to have my application connect to a db server?
Are most people simply using SQL authentication in this case?
Both machines are on a virtual cloud network.
If both computers are in the same domain, I'd use Windows Authentication for the SQL connection. To set it up:
Create a domain account to use for the app.
Give the id the absolute minimum priveleges necessary to host the site on the web server. For example, it must have read access to the web site itself, write access only to folders updated by the web site, etc.
Change IIS so that the domain account is used to run the app. In IIS6 & IIS7, you do this through the application pool. In IIS5, you have to change the settings in the machine.config or in the web.config for the ProcessModel.
All calls to the database will be done through this domain account; you won't have to setup impersonation. In fact, if you are using SQL authentication today, the only change you need to make is to the database connection string; no code changes are needed.