Difference between using a local system account and a domain user account (Microsoft sqlserver2000) (zt)

This article is reproduced in: difference between using a local system account and a domain user account (Microsoft sqlserver2000)

When installing sqlserver2000, this screen is displayed, which sets the login identity for starting the SQL Server service. After sqlserver2000 is installed, an MSSQLServer service is generated. Here, the logon identity of the service is set to start.  
So which one should we choose? What do they mean? Next, let's look at it.

Let's take a look at two concepts.

What is creden?
Windows credential refers to the user account and password. We call APIs such as wtsopenserver, queryservicestatus, and netuserenum that involve RPC, as long as the current user stores the creden with the appropriate permissions for the target remote machine, these Apis will not fail to be executed because of error_access_denied.
Is it hard to understand? Let's take a look at the access to other computers for better understanding. RPC is required to access a remote computer.
 
When we connect to the IP address 172.16.100.1, we need to enter the user account and password. Here, the user account and password are so-called creden.
 
After entering the user account and password, tick "remember my password" and click OK. Then, our creden (that is, this user account and password) are stored, so you do not need to enter them when you access them later.

Security Context
Security context refers to the security attributes or rules that are valid in a system.

The following describes two logon methods for the sqlserver2000 service: Local SYSTEM account and domain user account.

Local SYSTEM account:

This account is a predefined local account with administrator permissions on the local computer. The Service running in the security context of the Local System Account provides the local computer creden。 to the remote server. The Service running in the security context of the local system account cannot establish an authentication session because the local system account does not belong to the Everyone group in the domain. Therefore, services using this account can only access network resources through a Null Session (without creden. (This access refers to the automatic access to a task service, which is different from the concept of connecting to the SQL server)

Domain user account:

Use a dedicated domain user account as the Logon account

A domain user account is a user account created in the Active Directory Service. This account is a member of the Authenticated Users Group in the domain. The Service running in the security context of the domain user account provides the Kerberos ticket of the domain user account to the remote server. The Service running in the security context of the domain user account can access resources on the remote server authorized by authenticated users or specific user accounts.

Use a local user account as the Logon account

A local user account is a Windows User Account created on a local computer. The Service running in the security context of the Local User Account provides the access tag of the local user account to the remote server. If the user name and password are matched on the remote server, the service using the local user account can access resources on the remote server with the same name account. Although this solution works, maintaining these individual accounts and synchronizing their passwords will increase management overhead.
If you have not joined the domain but need to connect to network resources, you can use a local user account as the Logon account.
It can be seen that the domain user account can use creden。 to access the remote computer and use the corresponding resources.

For example, the sqlserver service needs to access a remote computer when it performs the following operations.
• Remote process call.
• Copy.
• Back up to the network drive.
• Heterogeneous connections involving remote data sources.
• SQL Server proxy mail and SQL mail.

In these cases, you cannot access a remote computer without using creden。 and use its resources. Therefore, you must change the logon type to "domain user account" and enter the existing "User Name" and "password" configured on the remote computer ".

If it is only installed on the local machine for development or learning, there is no need to use the domain user account logon mode, because sometimes the service cannot be started due to switching between different users.

Modify the login type of sqlserver Service

The service logon type can be changed at any time. You can use either of the following methods to modify the logon type of the sqlserver service as needed.

1. Modify through Enterprise Manager

Right-click sqlserver server --- "properties" --- "Start service account" under "security"
 

2. Modify through the service

"Control Panel" --- "service" ---- "MSSQLServer", right-click --- "properties" --- "login"
 

Some problems encountered when installing sqlserver
1. the prompt "command line option syntax error!" appears during installation! Type COMMAND /? For help"
This is because you may put the Installation File of sqlserver in the Chinese directory. You can change it to the English directory. Each level of directory cannot contain Chinese characters.
2. The following message is displayed: "A previous program has been installed to create a suspended file on the computer. You must restart the computer before running the installer"
Open the Registry Editor (or enter Regedit in the command line), find the pendingfilerenameoperations project in HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager, and delete it. Then install.

 

PS:

Local System/Network Service/Local Service permission

1. Local System ):
This account has high-level permissions.
First, this account is also affiliated to the local administrators user group. Therefore, all local administrators can perform operations on this account,
Second, the account can also control the file permissions (NTFS file system) and Registry Permissions, and even occupy the owner permissions to obtain access qualifications.
If the machine is in a domain, services running under the local system account can also be automatically authenticated by other machines in the same forest using the machine account,
The last point is that processes running in the local system can use Null Sessions to access network resources.
In addition, other core components in Windows user mode also run under this account, such as system32 \ smss.exe.
Note that the process running under this account uses the HKEY_USERS \. Default Account configuration, so it cannot access the configurations of other accounts.

For example, the services run with the LocalSystem account mainly include windowsupdate client, ClipBook, COM +, DHCP client, and messenger.

Service, task scheduler, Server Service, Workstation Service, and Windows installer.

2. Network Service ):
This account is also set to use the machine account to authenticate on other computers on the network. But he does not have as many permissions as the local system.
It can access network resources in the name of a computer. Services running in this account will submit access creden。 to remote computers according to the actual environment.
Processes running under this account use the network account profile HKEY_USERS \ S-1-5-20 and Documents and Settings \ NetworkService.
For example, the services run with the network service account mainly include Distributed Transaction Coordinator, DNS client,

Performance Logs and alerts, and RPC Locator.

 

3. Local Service ):
A local service account is a preset local account with the minimum permissions and has an anonymous identity in the network credential.
Differences between processes running under this account and those running under the network service account
The process running under the local service account can only access network resources that are allowed to be accessed anonymously.
The configuration files used by accounts running under the local service are HKU \ S-1-5-19 and Documents and Settings \ LocalService.

For example, services running with a local service account include Alerter, Remote Registry, smart card, SSDP, and WebClient.

 

 Local System/Network Service/Local Service permission list 

1. Local System:

Built-in account, which has a high level of access permissions. If the workflow ID runs as a "Local System" account, the workflow has full access to the entire system.

 

2. Network Services

The built-in account has fewer System Access Permissions than the "local system" account, but can still interact with the computer account creden。 through the network. For IIS 6.0, we recommend that you run the job ID defined in the application pool as the "Network Service" account. By default, the workflow identity runs as the "Network Service" account.

Default User Permissions:

Replacing a process-level token (seassignprimarytokenprivilege)

Adjust the memory quota of a process (seincreasequot1_vilege)

Seauditprivilege)

Ignore traversal check (sechangenotifyprivilege)

Access this computer from the network (SeNetworkLogonRight)

Log on as a batch job (SeBatchLogonRight)

Log on as a service (SeInteractiveLogonRight)

Allow local login (SeInteractiveLogonRight)

 

3. Local Service

The built-in account has fewer computer access permissions than the "Network Service" account, and the user permissions of this account are limited to the local computer. If a worker does not need to access a place outside the server, you can use the local service account. Default User Permissions:

• Replacing a process-level token (seassignprimarytokenprivilege)
• Adjust the memory quota of a process (seincreasequot1_vilege)
• Seauditprivilege)
• Ignore traversal check (sechangenotifyprivilege)
• Access this computer from the network (SeNetworkLogonRight)
• Log on as a batch job (SeBatchLogonRight)