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.
Related
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.
I'm having trouble configuring my ASP.NET web.config and my IIS web site to get the setup I want. Here's what I want at the end of the day:
The application connects to SQL Server using a particular NT ID
The NT ID used to connect to SQL Server is not in the web.config. Or at least its password isn't.
I can use HttpContext.Current.User.Identity.Name (or some other means) to get the NT ID of the real user that is connecting to the application.
If I setup an ASP.NET 3.5 in Visual Studio 2008, this basically is all working locally. But when I deploy to IIS, I can get the first two bullets successfully, but I can't get the third bullet. Identity.Name is null. The way I have it deployed right now is impersonation is set to true in the web.config, and IIS has anonymous access enabled with the anonymous user set to the NT ID I want to connect to the SQL Server.
The connection string I'm using to connect to SQL Server looks like this:
Server=[My Server];Database=[My DB];Trusted_Connection=Yes;
I have tried setting authorization to which was suggested in other posts, but that just makes Internet Explorer pop up a login box.
This is a Windows Server 2003 box running IIS 6.0.
This may very well be a stupid question, and/or duplicate question. But I've done a lot of searching and trial and error and I can't seem to get the magic settings.
By default, the machine\ASPNET account or the NETWORK_SERVICE account, depending on the version of IIS you are using (I'm not sure if IIS 7 is using NETWORK_SERVICE but 6 did). If you want a different account, the impersonation is applied on the configuration file (both user name and password) to run the account as. Now you can encrypt this part of the config section using the aspnet_regiis utility. But you have to supply an account. I don't think you can get away without this that I know of... unless maybe it can be done through IIS.
HTH.
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
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.
We've recently released the latest version of our intranet application, which now uses windows authentication as standard, and needs to be able to connect to a configured SQL server with the end-user's domain credentials.
Lately we've found that on a couple of customer deployments, although IIS can see the user's domain credentials, it will not pass these on to SQL server. Instead, it seems to use the anonymous account. This is in spite of following all the correct steps (changing the directory security to Win Auth, updating Web.Config to use Win Auth and denying anonymous users).
I've been doing a lot of reading that suggests we need to make sure that Kerberos is in place, but I'm not sure (a) how valid this is (i.e. is it really a requirement?) or (b) how to go about investigating if it's set up or how to go about setting it up.
We're in a situation where we need to be able to either configure IIS or the application to work for the customer, or explain to the customer exactly what they need to do to get it working.
We've managed to reproduce this on our internal network with a test SQL server and a developer's IIS box, so we're going to mess around with this set up and see if we can come up with a solution, but if anyone has any bright ideas, I'd be most happy to hear them!
I'd especially like to hear people's thoughts or advice in terms of Kerberos. Is this a requirement, and if it is, how do I outline to customers how it should be configured?
Oh, and I've also seen a couple of people mention the 'classic one-hop rule' for domains and passing windows credentials around, but I don't know how much weight this actually holds?
Thanks!
Matt
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
To run your application under the user's Active Directory or Windows credentials, ensure these:
the IIS application is set to NOT allow anonymous access
the IIS application uses Integrated Windows authentication
your connection string should have Integrated Security=SSPI to ensure the user's Windows/AD credentials are passed to SQL Server.
i.e. Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
You state you're not sure "how to go about investigating if it's set up or how to go about setting it up".
For this I'd heartily recommend a tool called DelegConfig. It's a very handy app that you can tell you if kerberos is setup properly.
Unzip it into a directory, configure a virtual directory in IIS to point to it. Browse to the main page and you tell it which backend server you want to allow access to (e.g. UNC, SQL, HTTP etc..) and it tell you its setup correctly or not and explain why.
It even has the abilty to recongiure the kerberos to fix the issue if you so desire (although I've not used this - I'd rather reconfiguire it myself to understand what I've done in future)
I realise this comes too late for your particular problem but thought it worth sharing for others that follow - especially the tools ability to explain why delegation is or is not working. I've found it invaluble.
Here's the situaiton. I'm working on developing a new website to access an old database. This is a DoD installation so there's lots of security around.
The current application is written in classic ASP, VBScript and some javascript. The new systems is ASP.NET.
Accessing the database in the old system meant hitting the server with your own credentials (domainname\username). Now I'm trying to test some of the early development I've done. When I used Cassini (under VS2008), I had no trouble getting to the database because ourdomain\myusername registered with the SQL Server instance as a trusted connection. Due to security aspects that I have to write, Cassini can't serve as a test server anymore - I have to use IIS (we have security card readers here). Cassini can't handle them.
So when I went through all the problems of getting the appropriate accounts added to Administrators on my local pc so that I could debug in VS2008 while using IIS, I tried to connect to the database and I was rejected because MYPC\ASPNET was not a trusted connection.
Altering the existing database is out of the question. Hard coding usernames and passwords for access to the database is out of the question.
I asked the DBA if he could add MYPC\ASPNET to of the domain groups so that SQL Server could see it as a trusted connection (since MYDOMAIN\MYNAME was in a group that was seen as a trusted connection). He tells me that is not technically possible.
In the end there are going to be three or four machines (mine, another developer, the eventual live web server and a future test web server) who's ASPNET accounts are going to be hitting our two SQL servers (live and test).
What do I have to do to make the existing SQL server see me as Friend and not Foe? I looked at impersonation but I get the impression it's not compatible with our system - the business rules make a call to a common routine to create a SqlConnection object and open it (maybe even a SqlTransaction object to go with it) and this object is used for the rest of the business rules and data-access layer until it's done. It didn't look like impersonation would persist once the SqlConnection was opened (and passed, ByRef back to the calling routine)
Thanks in advance for any advice.
You have two options:
Run your web application in an application pool configured to run in the context of a domain account
Use impersonation and configure your web application to use windows authentication only
Use Impersonation
As has already been suggested you should use impersonation.
However if your SQL Server is running on a different machine than your web server then impersonation will not suffice as the credentials of the user will not be delegated to the SQL Server (server hop). In that case you will have to either enable delegation in the AD or create a non-Windows login on your SQL Server and use that instead (this will not work if your SQL Server actually uses the Windows login for access control to tables etc.).
Sounds like you want to impersonate the client who is accessing your web site correct? Have you tried to use impersonation or are you assuming it won't work?
Edit
As Albert points out, impersonation requires the user to be authenticated using Windows authentication. You will want to disable Anonymous Access, and enable Windows Authentication in IIS Management tool.