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/
Related
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 have looked at numerous articles and tried a multitude of settings, but I can't seem to achieve what I'm looking for in my intranet site. Even if I don't get a solution, a definitive "you can't do that" will help me move forward. Here is what I'm trying to do:
Web site recognizes the user's network login credentials - ONLY so I can get their user ID without a login
The website uses some generic account (IUSR or something like that) to access a SQL Server that the same network users can NOT access EXCEPT through the website
Users can upload files to a set of folders created on-the-fly by the website to contain their files for later reference by them
The website can construct web pages on-the-fly with links to the users' files - and ONLY theirs - so they can open / download them through the web pages
Users can NOT access the uploaded files through a network share on the web server
All of the folder creation, file upload, and file serving occur under some generic account like IUSR
I currently have things configured to use Windows Authentication and I could probably live with that except I don't want to require a login to the site. Apparently, in order to make this happen, I need to have the server configured as a trusted delegate and IT is dragging their feet on doing that. Also, this config allows the users to access the SQL Server and folders/files through means other than the web site and I don't really want that. I only need to pick off their user ID so I can use it to get information about them out of Active Directory and keep track of their interactions with the web app.
In reviewing your post I must first say "Yes" it seems like what you want to accomplish can be done. However the enormity of your question precludes simple posting answers. From what I gather there are three security issues you want to navigate 1) Windows Authentication, 2) Admin only SQL access, 3) User only Access to files and directories while authenticated using Active Directory.
I have been building ASP.net intranet web applications using Active Directory (Windows logins) for a few months. I would encourage you to explore this article: http://www.mikesdotnetting.com/article/216/windows-authentication-with-asp-net-web-pages for details on setting up windows authentication in an ASP.net web application. You can add elements to your web pages using a section of Visual Studio [Toolbox] called 'Login', which contains elements such as 'LoginName'.
Next I am pretty sure you can control the SQL server query access using authentication parameters of your choosing. In the portion of the connectionString that is normally 'Integrated Security=True;' you will need to switch that to 'Integrated Security=False;username=sqlAdminUserName;password=sqlAdminPassword'. For more information I suggest reviewing this post: Integrated Security = False.
For the third security issue once you have isolated the user's windows login identity you should be able to dynamically build web pages, files, directories, and whatever other resources you require all customized for that individual user. I believe the generation of all those materials can be done with an IUSR account with the only needed ingredient being the Windows login user identity.
Good Luck and I hope my suggestions help move you ahead.
Actually, the answer is not all that complex and it is a real mystery why it is so difficult to find a single source on the web to spell it out. Here is my IIS authentication for an intranet app that acts exactly how I want:
Enable ASP.NET Impersonation and edit to Authenticated User
Enable Windows Authentication
Advanced Settings->Extended Protection->Off
Advanced Settings->Enable Kernel-mode authentication->unchecked
Providers->Available Providers->Negotiate:Kerberos and move that to the top
Disable all other authentications
Most critical: Make the server a 'trusted delegate' in Active Directory
That should do it.
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 have a site where the vast majority of the content will be secured using Forms Authentication. However there is one sub folder that will be used internally by the administrative staff. I would like to secure this folder using Windows Authentication. Is that possible? Would I have to make the admin folder a virtual directory?
CLARIFICATION: There is no need for the administrative staff to access the main site. They are really two separate sites/apps. Regular users will access the main application via Forms Authentication (and never access the admin folder). And admin users will access the admin application via Windows Authentication (and never access the main site).
Thanks,
Corey
Yes, it's possible but you have to build a custom membership provider or an interface to allow for it. It is not possible to specify individual authentication methods on sub-folders unless they are in completely separate projects/application domains.
One method to accomplish this would be to use an LDAP membership provider and change the ldap connection based on the username (if there is a discernible method of doing this).
One other method would be to provide a separate website that uses the Windows authentication to perform the login and then constructs a custom cookie for the user and transfers them back to the original website identifying the individual as a member of the administrative staff.
Then the folder could be secured using the <location> elements in the web.config.
If I was going to build a site with Mixed authentication, I would setup the site to use webforms. I would then setup a virtual application inside of this application that consisted of the same forms auth web.config information but set to use Windows Auth.
On the login page of the windows auth site after you validate their credentials I would then manually call FormsAuthentication to create the auth token. At this point you can then redirect the user to the Forms Auth site and they should be logged in (as long as all the forms auth cookie information is the same for both sites, this might also include needing to setup the same machine keys for both applications).
I haven't done this specifically but this should definitely be a viable (and probably one of the most optimal) solutions.
It may be as simple as right-clicking on the admin folder in Windows Explorer and setting the rights in the Security tab.
Put the administration site in its own application - by right clicking on the folder in IIS manager and and choose convert to application.
Once that's done you can adjust the authentication method on the application by highlighting the application folder in IIS manager and then choosing authentication and adjusting them (or you can do it the hard way via web.config if you can't remote into the machine).