access|asp.net| Access | data | The database is also a common problem, especially under WIN2003, who is often asked.
A connection exception is usually caused by disk permissions, and the system default ASP.net account has minimal privileges for the NTSF partition and may cause an access exception. The solution is to fix the appropriate permissions in the system.
Another: The exclusive access method specified in the connection string may also cause a connection exception. This situation can only be fixed by fixing the connection string.
Such as:
Conx. ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0; password=; User id=admin;data source= "+ Server.MapPath (" data\\ elegant holiday. mdb ") +"; ";
Can
Attach MSDN about creating custom accounts to run ASP. NET articles to facilitate understanding of security deployment asp.net projects.
----------------------------------------------------------------------------------
How to create a custom account to run ASP.net
Microsoft Corporation
Goal
This module is used to:
• Create a least privileged account with sufficient privileges to run the ASP.net application correctly.
• Configure ASP.net to run using a custom least-privileged account.
Apply to:
This module applies to the following products and technologies:
Microsoft_ Windows_ XP or Windows Server (with Service Pack 3) and later operating systems
Microsoft. NET Framework version 1.0 (with Service Pack 2) and later
Internet Information Services (IIS) 5.0 or 6.0 (only if you are using IIS 5.0 isolation mode)
How to use this module
Use this module to the fullest extent:
• Must have experience in developing asp.net Web applications and be familiar with the use and structure of machine.config files.
• You must have experience using Windows management tools to create and manage stand-alone or domain-based Windows user accounts.
• Reading module "asp.net security". This module will provide you with more information about how ASP.net security works, how the worker process identifies the impact on the permissions of an executing application, and how you can use impersonation to easily grant the appropriate permission level to users of the Web application. asp.net
Summary
By default, each ASP.net worker process runs in the context of the least privileged account named ASPNET. If the ASP.net application is deployed on a domain-based server, or if you need to access resources on a remote server, you can simplify management by configuring ASP.net to run in the context of different accounts.
This module describes how to configure ASP.net to run in the context of a custom local or domain account, and describes the permissions that are assigned to this account to work properly.
Preliminary knowledge
Before you start using this module, you should know the following:
asp.net worker process identification
The default account that is used to run ASP.net (created at installation time) is a least privileged local account and is specified in Machine.config as follows:
<processmodel enable= "true" username= "Machine" password= "AutoGenerate"/>
This account is identified under the local user and group as ASPNET and has a strong password that is secured in the Locals System Authority (LSA).
When you need to use the ASP.net process identity to access network resources, such as a database, you can do any of the following:
• Use domain accounts.
• Use a "mirrored" local account (that is, an account that matches the user name and password on both machines). This method is required when the computer is in a different domain that does not have a trust relationship, or when the computer is separated by a firewall and cannot open the ports that are required for NTLM or Kerberos authentication.
The easiest way to do this is to change the password for the ASPNET account to a known value on the Web server, and then create an account named ASPNET with the same password on the target computer. On the WEB server, you must first change the ASPNET account password in Local Users and groups, and then replace the credentials on the <processModel> element in Machine.config. You should not store plaintext passwords in Machine.config, but instead use Aspnet_setreg.exe to store encrypted passwords in the registry. For more information, see Module 8, "asp.net security."
<processmodel enable= "true"
Username= "Registry:hklm\software\yoursecureapp\processmodel\
Aspnet_setreg,username "
Password= "Registry:hklm\software\yoursecureapp\processmodel\
Aspnet_setreg,password ". ./>
You can use the steps provided in this module to create a local account with minimal privileges.
Simulate a fixed identity
You can set a fixed identity for a specific virtual directory by using the following settings in Web.config. Use Aspnet_setreg.exe to store the encrypted credentials in the registry.
<identity impersonate= "true"
Username= "Registry:hklm\software\yoursecureapp\
Identity\aspnet_setreg,username "
Password= "Registry:hklm\software\yoursecureapp\
Identity\aspnet_setreg,password "/>
This method is typically used if you have multiple Web sites on the same Web server that need to be run in a different capacity, for example, in an application hosting scenario.
This module describes how to create a local account with minimal privileges. If you are primarily managing, you can use a minimal privileged domain account with a strong password.
When considering the account used to run ASP.net, keep in mind the following points:
• By default, ASP.net is not emulated. Therefore, any resource access that is performed by the Web application uses the ASP.net process identity. In this case, the Windows resource must have an Access control list (ACL) that grants access to the ASP.net process account.
• If impersonation is enabled, the application accesses the resource using the security context of the original caller, or if IIS is configured for anonymous authentication, the anonymous Internet user account is used (Iusr_machine by default). In this case, the resource must have an ACL based on the original caller identity (or iusr_machine).
• Always follow the principle of least privilege when creating custom accounts-providing only the minimum required privileges and permissions.
• Avoid running asp.net with the SYSTEM account.
• Avoid granting "as part of the operating system" privileges to this account.
Create a new local account
This procedure creates a new local account. By default, this new account will be added to the local Users group.
To create a new local account, do the following:
1. Create a local account (for example, "Customaspnet").
Make sure that you use a strong password for this account. A strong password should contain at least seven characters and take uppercase and lowercase letters, numbers, and other characters (such as *,?). or $) in a mixed way.
2. Clear the User must change password the at next logon option.
3. Select the Password never Expires option.
Assigning minimum privileges
This procedure assigns the smallest set of privileges required to run asp.net.
To assign a minimum privilege, do the following:
1. From the Administrative Tools program group, start the Local security Policy tool.
2. Expand the local Policies and select User Rights assignment.
A list of privileges is displayed in the right pane.
3. Assign the following privileges to the new account:
• Access this computer from the network
• Log on as a batch job
• Log on as a service
• Deny local logon
• Deny logon through Terminal Services
Note To assign privileges to an account, double-click the privilege, and then click Add to select the account that you want.
4. Close this tool.
Assigning NTFS Permissions
This procedure grants the required NTFS permissions to the custom ASP.net account in the local file system.
Note the steps in this procedure apply to the file system on the WEB server (not to the file system on the remote computer, which can be replicated on the remote computer for network authentication).
To assign NTFS permissions, follow these steps:
• Start Windows Explorer and assign the appropriate permissions to the folder specified in table 1.
The fixed impersonation account mentioned in Table 1 refers to an account that can be selectively configured using the <identity> elements in Web.config, as shown below.
<identity impersonate= "true"
Username= "Registry:hklm\software\yoursecureapp\
