We are currently moving an old ASP.net web application from a hosted server IIS7 to Azure.
In the current setup the site is accessing a File Server using an UNC path to a shared folder on the file server.
\\file-server\files-client
We do, for now, not want to change this approach since it will substantially complicate the moving process.
We have set up an Azure Storage with File Service and a share in this called files-client
This can be access perfectly from a VM by setting up credentials and accessing it via
\\storageaccount.file.core.windows.net\files-client
But
We really would want to have this site run as a Web App Service since it gives us a number of advantages.
We have set up an App Service, have published the Web Application, and all is running great including DB access etc.
Unfortunately our luck runs out when the Web Application tries to access the file share using
\\storageaccount.file.core.windows.net\files-client\test.jpg
We get an access error:
Access to the path '\\storageaccount.file.core.windows.net\files-client\test.jpg' is denied.
This tells me that the App Service sees the share but is not authorized to access it.
I know that we somehow has to grant the App Service access to this storage, but searching the net intensively tells me that this cannot be done which I simply cannot understand, and hopefully I'm not looking in the right places.
Sp the question is: How do I set up the credentials in the App Service to have it access my Storage share?
Any guidance is much appreciated.
Thanks in advance
The App Service sandbox explicitly does not allow access to the ports necessary for SMB protocol (137/138/139/445).
This article mentions it under Restricted Outgoing Ports: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox.
Related
Scenario
I have an application that I have been developing for two years. I use the framework .NET to develop it in a language called Oxygene that comes from Pascal.
When I have something new in my code, I publish my application in File System method. I have a couple servers working on Amazon EC2, so I transfer this files to a folder in my IIS Server. In this IIS Server I already have a website that corresponds to my application, so I just replace the old files for the newest files.
I have another server that works as an SQL server.
Last detail is that in my application the user is able to attach files, import pictures, export PDF and Excel files. Attachments and pictures are stored in the same folder the application is located.
Issue
Here is my problem. I have got a new client that is kind of a big client. It seems like this company has a strong IT security, so the application must be located in their servers.
The big problem is that they required my application to be set in the following architecture:
I am used to only use an app server (works for external access) and a SQL server. They want the third server in DMZ net so they can let external access happen. The reason the application can't be placed in the DMZ is because there are the files I mentioned bellow that the user stores in the application. The database stores all the data, but not those files mentioned.
Solutions I have offered, but won't be accepted:
Publishing the application in a IIS server located in the DMZ: That won't be accepted since my application stores user attachments in the same folder the application is located. There are also images stored there.
Publishing the application in the app server, but also publishing a empty application in the DMZ server redirecting to the IIS server inside the LAN: That's the best solution I have come up.
Using a reverse proxy to protect the LAN Net: This is off the table, since reverse proxy is not safe at all.
I am kind of confused because I can't see a way to separate my application in two to make it work in that suggested architecture.
Can anybody give me a hint or ideas of how this would work?
-
You can't "redirect" to inside the LAN, a redirect is a client-side operation, so if the internal server isn't already exposed, you can't redirect someone to it.
A reverse proxy is likely your best bet. Why do you believe it is not safe? This is a tried-and-true solution, it allows you to leave additional ports/services open to internal requests (like a file server, which it sounds like you are trying to expose).
How are these files getting uploaded? Are you using FTP? SMB? HTTP? This solution will not expose those other protocols to the outside world (please don't expose SMB to the outside, it will result in tragedy). Do the external users need to upload these files?
I am trying to deploy a WCF service that uses a SQLite DB to read some data as well as connecting to another Database (MS SQL). The service itself is consumed by a ASP Web site running on the same server.
The problem is that only my user is able to fully use the website and service. Every other user can't seem to open the sqlite database file.
What kind of permissions or special access do you need to access a sqlite database from IIS?
The Application pool is setup with a domain account so that access to the MS SQL Database can be granted (Integrated Security).
The folder where the database is stored is accessible by the account. And I've even tried to make it accessible by Everyone and all users with no luck.
I feel I'm missing something obvious but I can't figure out what...
Update: The error is as follows:
System.Data.Entity.Core.EntityException
An exception of type 'System.Data.Entity.Core.EntityException' occurred in EntityFramework.dll but was not handled in user code
Additional information: The underlying provider failed on Open.
Inner Exception:
System.Data.SQLite.SQLiteException
Unable to open database file.
I was able to resolve the issue, I'm going to document it here for posterity. I took a few steps to do so, and I currently don't have the environment set up to be able to reproduce the issue consistently and quickly, so I'm not entirely sure which was the actual solution.
Disclaimer aside, here are my changes:
I created a new Application Pool and Website on IIS, on another directory entirely, not on "C:\inetpub\wwwroot". I used "C:\Sites\MySite" to deploy both my WCF service and the website which consumed it.
I changed the application pool identity account to a new AD Service account.
I placed the database inside of the Service Web App directory, within a directory called data. I removed all inherited permissions from the directory and the database file, and gave the both the service account and Everyone Full Control of the directory and database file.
I edited the connection string for sqlite to have the setting "Journal Mode=Off;".
I stopped and started both the Application Pool and the WebSite on IIS.
After this the service worked correctly, and I was able to access both the database file and the connection to SQL Server. If I get the opportunity, I would set up some kind of virtual network to replicate this and see if I could figure out exactly what caused the error in the first place.
I have an ASP.NET MVC Application running as an Azure Cloud Service WebRole and I need to b able to upload files to my /Views/Whatever directory so I can quickly edit files on the fly without having to re-publish which can take 30 minutes.
How can I set the permissions to allow me to save files to this path?
If it's a single instance Web Role (which I assume it would be, I can't imagine you editing files on each one of the instances), then you can just enable Web Deploy on your deployment and be done. Then you can use Web Deploy to send the updates to your site without having to RDP. Just keep in mind that if for whatever reason the machine has to be moved or re-imaged (e.g. host updates) you'll lose your changes if they are not part of the Cloud Package (cspkg).
You can enable the option as part of the deployment of your Cloud Service.
I have an internal ASP.NET MVC 2.0 web application that employees can upload documents to. I am then copying these files to another server for processing. Currently the web application (IIS 7 .NET 4.0) is running under an application account we set up (i.e. WebApp => Basic Settings => Connect as..). This application account has read/write ability on this other server (both share and file security. It was also set as a local admin at one point), but when I try to copy a file to the other server (I can copy/create files on the local server just fine) I get:
System.UnauthorizedAccessException: Access to the path '\\NotTheWebServer\BlahBlah\Blah.pdf' is denied.
If I give "Everyone" share rights to this folder it works. I don't want give everyone write access via the file system.
My Question: Is this just poor practice to do what I am trying doing here? If so what is the best way to accomplish this goal?
Thanks,
Mike
This was stupidity/ignorance on my part. I needed to change the user rights on the application pool associated with with this web application not the rights on the virtual directory. Once the user rights were changed on the app pool everything worked as expected.
I have an ASP.NET web application that runs on a windows server 2003 server.
there is a form that reads and writes data to an xml file inside the application's directory.
I always grant the NETWORK SERVICE user full control on my application folder so that it can read and write to the xml file.
I put the application on another windows server 2003 server and did the same steps above but i was getting an Access denied exception on the form that reads and writes to the xml.
I did some search and found that if you grant the user ASPNET full control to the directory it would work, I did that and it worked fine.
my question is: what is the difference between granting full control permissions to NETWORK SERVICE and ASPNET users ?
and what can be the difference between the two servers that caused this issue ?
thanks
In all cases, you need to grant the application pool's user account the appropriate access. Application pools were introduced with IIS6. Before IIS6, the .NET application ran under the user account configured in the machine.config file so you would look there to determine the user that needs access.
Network Service is assigned to application pools by default. It sounds like someone set it up differently on one of the servers.
Ideally, you should not be using either account.
You should create a low privilege account that only has access to the resources you need for each web application you have. Add the new account to the IIS_WPG user group. Then create an application pool for each application and set it to run as the user you created specifically for it.
See this article (TechNet) for directions on changing the identity of the app pool.
The configuration I described is now the default in Server 2008 R2/Win 7 (source).
Unfortunately, because someone changed the default configuration on your second server, there is no way for us to tell you what the differences between the two accounts are.
What you will need to do (or have your IT department do) is compare the permissions each account has on the local machine. This will be tedious. However, if you can run powershell, you can use this article to write a script to list out the permissions for each account and compare them.
Good luck finding the differences.