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
Related
How do I secure one aspx page with basic authentication, in a website running IIS 8 (Windows Server 2012)? The Forms authentication is used elsewhere on the website, but I need a temporary protection to this particular file with Basic Authentication.
In IIS, I have disabled anonymous authentication on the folder where the file resides, and enabled the Basic Authentication. I have also created the new local user, and given it permissions to read the folder. I would like to use this username/password to access the resource.
Yet, I can access the file without seeing any user name/password prompts.
Try the steps below:
On the IIS Manager application, access your website and select the directory that you want to protect.
On the right part of the screen, access the option named: Authentication.
Disable the Anonymous authentication on the selected directory.
Enable the basic authentication on the selected directory.
In this example, i configured the IIS server to use the basic type of authentication and configured the IIS server to require authentication to access a directory. As an administrator, create a local user account.
net user /add xxxx
To test the installation, open the browser and try to access the protected directory. Enter the URL in the Browser, the IIS server will require you to perform the user authentication.
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/
I have decided to transfer several of my web applications from one virtual server ot another. The way everything works on my current server is pretty bad - everyone has rights for reading and accessing the content of my "applications" folder on the machine, and so does the IIS. I want to organize stuff on the new server, so only IIS can access this folder.
I have installed IIS and the ASP.NET addons on the new server, and forced my test website to Windows Authentication, as all of my websites are configured on the current server. Then, after doing some reading regarding the permissions, I have given full control to the folder that contains my website to the next users: IIS_IUSRS & TestAppPool (which is the Application Pool I have created for my 'Test' application).
For some reason when I try to access the website from another user within the domain, through the browser, it promts for Login Credentials. I would like to understand why my application wont retrieve the permissions I have granted the IIS users upon accessing the website.
not sure if this would help, but can you try changing the app pool's identity to Network Service?
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 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.