Security Context of Asp.net refers to what identity of the ASP.NET's working process (Worker Process) in other access resources (such as SQL Server's service or network sharing folder).
Take SQL Server as an example, when the ASP.NET application code attempts to connect SQL Server with Windows integration login mode (instead of using SQL Server Login ID), SQL Server thinks who is trying to connect?
Alternatively, the ASP.NET program may need to access a shared folder // fileserver / share represented by UNC path, which will think who is trying to operate?
There are many factors affecting Security Context. Before analyzing these factors, we must first clarify two points:
(1) IIS service itself's Service Account (default is Localsystem) is not an influential factor
This is because the ASP.NET program does not work in the IIS's service process, but run in a working process called "ASP.NET WORKER Process", this work process is similar to a Windows Service, but in the Windows Service list Can't see it. The control program for this working process is an exe file: ASP_WP.EXE (ON Windows 2000) or W3WP.exe (ON Windows 2003).
In contrast, many other service SECURITY CONTEXTs are Service Account, such as SQL Server storage processes, when trying to access resources on other machines, their identity is the launch account of the MSSQLServer service.
(2) There is no difference between the ASP.NET web application page and the ASP.NET Web Service on the issue of Security Context. Because both work in ASP.NET WORKER Process.
Actually affected ASP.NET Security factors include:
(1) The version of the Windows system (more exactly IIS) where the ASP.NET program is located.
(2) ProcessModel settings in Machine.Config
(3) ASP.NET IMPERSONATION settings
(4) IIS's anonymous access user account settings
(5) IIS and access resources (such as SQL Server) are on the same machine
(6) The accessible external resource is SQL Server, or a File System (such as a UNC shared folder path)
Windows 2000 Server with IIS 5.0
See the situation on Windows 2000 Server first.
Machine.Config's ProcessModel
Locate the Machine.config file in the /%windows% / Microsoft.Net/framework/Version/config directory, with a
The username = "Machine" is to specify the default account using the native ASPNET account (./ASPNET) as an ASP.NET work process.
This default account is modified, if the developer changes username to a domain user account:
Enable = "True" Username = "domain / user" Password = "password" /> Then the identity of the ASP.NET work process has become Domain / User. As long as this domain user account has a needed permissions, all ASP.NET programs on machine.config can access resources from other servers in the domain, including access to files specified with UNC paths. If you specify username = "system", the ASP.NET program will run as localsystem, you can access almost all local resources, so it is very dangerous! No matter which default account is specified, this default account can be overwritten by the Impersonation setting of the application's web.config, that is, the specific application can run in other identities. Web.config Impersonation There is a There are two possibilities to play: (1) Play the IIS service requestor, the identity of the browser client Setting in Web.config: The ASP.NET process will play the identity of the HTTP / HTTPS requestor. For details, it is related to the security settings of IIS: If IIS allows anonymous access, then in the default, it will be the Iuser_machine account, which is the account specified by Enable Anonymous Access in the IIS security settings. If you have modified, that is played is a modified account. If IIS does not allow anonymous access, the identity of the browser requester is definitely a Windows account, this account is the object being played. (2) Play a fixed user Setting up a fixed user identity, you need to specify both UserName and Password two attributes for the Obviously, it is not appropriate to write the password in Web.config. The recommended approach is to use the ASPNET_SETREG.EXE tool to save this information to the registry. No matter which account, Microsoft is not recommended to use the play, one side is the security problem (the accounts that may be played may have some programs, which may be utilized), and on the other hand is a scalability problem (SCALABILITY) Because when accessing resources such as SQL Server, connect pools cannot be utilized. Resource server and IIS separation The above mentioned .aspnet, iUser_machine is this unit, that is, only on the machine where IIS is located, if the ASP.NET code is trying to access resources on other machines, such as SQL Server or UNC path, then resource server is not recognized of. In the file server, it seems to be a 'NT Authority / Anonymous Logon' account attempt to access, for SQL Server, if the code is logged in with Windows integration security mode: (NULL) Account Login failed. There are several ways to solve this problem: (1) Discount the Guest account on the resource server (2) Change the anonymous access account of IIS to a Domain / User (3) Play in web.config and play a Domain / User The first method is the most taboo of security, so don't do this. Like the two methods, it is to access the identity that can be approved by a resource server. This method also has a problem: Domain User may have some privileges that do not need. What is even more trouble is if the network tube or who has modified the password of that account, the application will have a problem. Moreover, if you want to play Domain User, the password saves a headache: cannot be placed in Web.config, you have to add it in the registry. The password is encrypted, and the encrypted key has become a hot saggy, and it is afraid to see it in the misery, and it is afraid to lose. So the real good way is to upgrade the Windows 2000 where IIS is located, use Windows Server 2003! Windows Server 2003 with IIS 6.0 Look at the situation on Windows Server 2003. Windows Server 2003 is written with the IIS's kernel, so its IIS 6.0 is very different from the IIS 5.0 of Windows 2000 in many ways. From the perspective of ASP.NET Security Context, the biggest difference is: (1) The control program for the ASP.NET work process is different: not ASPNET_WP.EXE, but W3WP.exe. (2) Although it is also created when the .NET Framework is installed. /Spnet account, Machine.config also specifies the processModel username = "Machine", but the meaning is not used ./ASPnet account, but use NTAUTHORITY / NETWORK Service, The default identity of the ASP.NET work process. This NetWorkService account is a new special account introduced by Windows 2003. It is similar to localsystem. This account is a virtual account. It can be used as a startup account for Service, but it is very limited to local resources, so this account is a service to start accounts with this account. Process, there is little permissions such as resources such as local documents, so that the security of the Windows system can be better guaranteed. For ASP.NET programs, the ASP.NET work process is default to network service, providing a great convenience of accessing IIS outside the program code: When the program code is trying to access resources on other machines (SQL Server Or UNC), its identity will no longer be Anonymous Logon, but an IIS machine account: Domain / MachineName $. This is the so-called "delegate" mechanism. NetWorkService is like a small staff, which is very low in the company, but it is representative of the entire company. Therefore, the ASP.NET program running on the IIS of Windows 2003, if you need to access SQL Server or file resources on other machines, you only need to authorize the IIS computer account on the resource server, neither need to modify the IIS anonymous access account. Needless to set up, save a lot of trouble. Take SQL Server as an example, if you need to allow the program on IIS to log in and access a database, just run the following SQL script: EXEC SP_GRANTLOGIN N'DOMAINNAME / IISMACHINENAME $ ' Use [DatabaseName] EXEC SP_GRANTDBACCESS N'DOMAINNAME / IISMACHINENAME $ ', N'IISMACHINENAME $' EXEC SP_ADDROLEMEMBER N'DB_OWNER ', N'ISMACHINENAME $' This uses a computer account to make resource access, you can also get two benefits: (1) Database connection can use Windows integrated security mode, and the connection string can be stored in Web.config, such as: Integrated security = SSPI; Initial Catalog = (2) In normal case, the computer account does not have any permissions to other network resources, so the entire system complies with Least Privilege principles, and there will be no unassays.
