I have ASP.NET project which do some file access and manipulation, the methods which I use for file access are below. Now I need to access files on another server shared folder, how to do that? I easily can change file path to shared folder path but I get "can't access" error because shares are password protected.
As I understand I need somehow to send credentials to remote server before executing methods below. How to do that?
FileStream("c:\MyProj\file.doc", FileMode.OpenOrCreate, FileAccess.Write)
Context.Response.TransmitFile("c:\MyProj\file.doc");
Regards,
Tomas
An ASP.NET application (by default) will execute in IIS6 under the "ASPNET" computer account. You therefore have a couple of options:
Configure your ASPNET application to run under a (weak) domain account with permissions to access the remote computer's share
Set the permissions on the share to enable access to "Everybody" (not recommended)
Disable Forms authentication and use Windows authentication in your ASP.NET app. Turn off impersonation in web.config and IIS should pass the credentials of the user who is currently using your web application through to the underlying share (I think).
The latter option is only useful, of course, if your users all have domain accounts on your intranet, for instance. I'll continue to look around for ways to add credentials but I'm not sure off the top of my head if that's possible.
HTH,
Richard.
Related
What risk is a user exposed to if he accesses a .net web application with impersonation enabled?
What impersonation level is ASP.NET impersonation?
This is the documentation of impersonation-levels.
Can I create a website, then lure a sysadmin to open it and do some bad stuff in his name (like adding me to the local sysadmins. I can deploy web applications but I am not an admin)? What are the boundaries of this impersonation? Did not find any precise description in the docs.
First of all you need to understand what is ASP.NET Impersonation. Apart from msdn given definition, in layman language, ASP.Net impersonation is ability to get user information of Active Directory Logged-in user on machine using client side asp.net application.
As you mentioned, there are different impersonation-levels.But before going to that you need to understand that ASP.Net is managed environment. It exist under the scope of IIS application pool. So any application is ability is limited to what an web application in managed environment can do on server.
To directly answer your concerns, these are few considerations:
If you can host an application is IIS having ASP.impersonation, you should be admin of that machine(non-admin users can't even open IIS)
Any IIS application can't do Administrative tasks like Creating, deleting users, changing user permissions without calling any native application for manipulation active directory(need to configured & much work needs to be done, non admin can't think of that). That is almost impossible even somehow possible with some 3rd party unmanaged code then also non-admin user can not install those tool/sdk on server without having direct access to servers.
ASP.Net impersonation is mainly for active directory users and Active Directory exists in securely managed environments in VPN or Office Premises. You need to be active directory user to access impersonation. Even somehow you did that(not possible without admin server access) then also audit/system logs/network logs will find who is insider culprit to did something like that so what that means inside an organisation(apart from getting fired) I leave upto you.
Still you think asp.net impersonation is unsafe, you can ask questions. :)
UPDATE for comments
Impersonation Level link you got above is for desktop/windows application which runs in full trust. ASP.net application impersonation is just a way to get identity of Active Directory User with some defined attributes and it is mainly used for authentication & authorization. I again reiterate, ASP.net is managed application inside App pool which only can perform action which is authorized to Account from which you have hosted application and with that too native/administrative actions like creating or modifying Active Directory User access is not possible without calling some another SDK which is already trusted & installed on that machine.
So summarize, operations like creating files or deleting file on the place where you have given Directory access to Web App is possible(Also on network if permission exists while deploying for User used for hosting not logging in) but deleting everything on server or performing Administrative tasks like AD User creation/modification is not possible via login of Admin impersonation of ASP.net webapp without assist of already installed trusted unmanaged software that can do this.
I had a palaver with my sysadmin yesterday. If the user is authenticated by kerberos, it is possible that the webapplication accesses resources on other servers in behalf of the user (delegation). Kerberos constrained delegation works with a white-list.
If my application needs to read files on a file share with credentials of the logged in user, the security admin has to add an entry that my application (identity of app-pool) accesses this file server in the name of the logged in user. I can not create a malware application that reads all the emails of my boss just because he is visiting my webapp.
See https://blogs.technet.microsoft.com/pie/2017/06/30/credential-theft-made-easy-with-kerberos-delegation/
We have a web application that copies files to a remote server within our domain (OurDomain). The following issue occurs with users that log on to their laptop with another domain, and then log on to the web application with OurDomain. Users that log on to both the laptop and web application with OurDomain\User don't have this problem.
We have two webforms:
The 1st webform retrieves the user's ID using System.Security.Principal.WindowsIdentity.GetCurrent() and then sends an email with this userid. This code retrieves the user's ID only if we have Windows Authentication set to Enabled and ASP.Net Impersonation also set to Enabled. If ASP.Net Impersonation is set to Disabled, the user will be Network Service. So I set both to Enabled and everything here works great.
The 2nd webform copies some files to the remote server, also under the domain OurDomain. With Windows Authentication set to Enabled and ASP.Net Impersonation set to Disabled, then Network Service is used to copy the files to the remote server and are copied correctly. On the other hand, If ASP.Net Impersonation is set to Enabled, it seems to bypass Network Service and even OurDomain\User and tries to copy with, apparently, the credentials used to log on to the laptop (Another domain). The files don't copy and I get error Access to the path is denied
The only fix I've found is to add OurDomain\User to the folder, and it's really not a big deal, but I wanted to see why this was happening.
Thanks.
I believe OurDomain\User is the user who is logged into the system from web browser. It is not a good security practice to give server folder access to that group of users. If you give access to those users they can even browse the remote folder without your web application.
NetworkService is a user who has role on in the system where it is created.
Better create a user as asp.net appPool user in OruDomain\webappuser ie the user who runs the w3wp worker process. Let the password with be the admin.Give OurDomain\webappuser the permission on the remote folder. Run the web form without impersonation.
Now the files which are received via file upload dialog in webform2 can be copied to the folder safely as the asp.net application run in the context of OurDomain\webappuser
I'm new to Encrypting File System (EFS). I have an ASP.NET web application hosted on Windows Server 2008. The web application saves some files in a local folder on server. When I applied the EFS (Encrypt contents to secure data) attribute to the folder while using an administrator login, the files inside got encrypted and are not accessible to other users. But, now the web application also cant access the files. The web application is set up with forms based authentication. How can I permit the web application to access the files?
EFS is designed to really only allow the user that encrypted the data to see it. Since you encrypted the value as the administrator user the user your application is running as (NETWORK SERVICE or whatever you've configured) doesn't have access. You need to give them decrypt rights on the folder. Forms authentication has no bearing on this, as it doesn't interact with the Windows-level security.
You can specify the user by going through the Details section of the folder properties window and then specifying the web app user. You may have to enable loading user profile for the application pool though.
But with all that being said, I don't actually know if EFS will let IIS decrypt the data. Googling around hasn't proven successful.
I'm creating a website which besides other tasks will play some recorded files. these recorded files are on a remote server with private ip address, so I've created a virtual directory which points to a share directory on the mentioned server.
now I'm able to playback the files using client side controls like wmplayer. BUT the problem is sound file urls are accessible without any authentication and authorization.
is there anyway to enforce .net authorization and authentication (in web.config) on this virtual directory? I also should mention I can not use solutions like httphandlers to download the files because file are streamed using iis so user could navigate on the file without downloading all of it)
thanx
Open IIS (I suppose you use IIS7.0 or later). Find the mentioned virtual directory and click on it. In the listed features find Authentication, right click on it and press Open Feature. Then disable anonymous authentication for this folder. Does the problem persist?
I am trying to use a textreader to retrieve data from a text file on a local machine. I have an upload routine to get the file for the reader to open.
When I run the application locally, it works fine. When I publish my application to my server, I am getting a Could not find a part of the path error. I assume this error has to do with permission in that the server cannot read from the local file system, but I don't know the proper way to remedy this.
do I set up the application to impersonate the user? I know I can't possibly set up each local users machine to allow the iusr account to access it.
Thanks for any thoughts.
UPDATE ****
I ensured that network service is they user for the app pool. I also ensured that the networkService has access to the local folder that the application resides in. I am running IIS7, and when I test the site, I am getting the error -
The server is configured to use pass-through authentication with a built-in account to access the specified physical path. However, IIS Manager cannot verify whether the built-in account has access. Make sure that the application pool identity has Read access to the physical path. If this server is joined to a domain, and the application pool identity is NetworkService or LocalSystem, verify that <domain>\<computer_name>$ has Read access to the physical path. Then test these settings again
I have tried suggestions from various posts, including adding domain\servername$ to the folder to allow access, but nothing seems to work.
Any thoughts?
Assuming this is IIS 6.5 or higher, the application pool user must have the necessary permission. By default, this is Network Service, which likely does not.
I solved this issue by first saving the file to the server, and then accessing the server's local file -
savedFileName = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, Path.GetFileName(file.FileName));
file.SaveAs(savedFileName);
The following blog helped me out - http://www.hanselman.com/blog/default.aspx?date=2008-06-28