zoukankan      html  css  js  c++  java
  • Service Logon Accounts

    About Service Logon Accounts

    When a Win32-based service starts, it logs on to the local computer. It can log on as:

    • A local or domain user account.
    • The LocalSystem account.

    The logon account determines the security identity of the service at run time, that is, the service's primary security context. The security context determines the service's ability to access local and network resources. For example, a service running in the security context of a local user account cannot access network resources. Conversely, a service running in the security context of the LocalSystem account on a Windows 2000 domain controller (DC), would have unrestricted access to the DC. For more information, and a discussion of the benefits and limitations between user accounts and LocalSystem, see Security Contexts and Active Directory Domain Services.

    Ultimately, administrators on the system where the service is installed have control over the service's logon account. For security reasons, some administrators may not allow you to install your service under the LocalSystem account. Your service must be able to run under a domain user account. As a programmer, you can exercise some control over your service's logon account. Your service installer specifies the service's logon account when it calls the CreateService function to install the service on a host computer. Your installer can suggest a default logon account, but it should allow an administrator to specify the actual account.

    Your installer can also perform the following tasks relating to your service's logon account:

    • Installation. If installing your service to run under a user account, the account must exist before you call CreateService. You can use an existing account or create one as part of the host-computer installrt. For more information, see Setting up a Service's User Account.
    • Authentication. If you want clients to use Kerberos mutual authentication, register the SPNs on the service's logon account. If the service runs under the LocalSystem account, the service's logon account is the computer account of the host computer. For more information, see Service Principal Names.
    • Grant Access. Ensure that the service at run time has the access rights and privileges that it requires to perform its tasks. This can require setting access-control entries (ACEs) in the security descriptors of various resources, that is directory objects, file shares, and so on, to allow the necessary access rights to the user or computer account. For more information, see Granting Access Rights to the Service Logon Account.
    • Set Privileges. Assign privileges to the specified logon account, such as the right to logon as a service to the host computer. For more information, see Granting Logon as Service Right on the Host Computer.

    After a service is installed, there are maintenance tasks that relate to your service logon account. For more information, see Logon Account Maintenance Tasks.

      • Password maintenance. For a service that runs under a user account, you must periodically change the password and keep the password in sync with the password used by one or more local service control managers to start the service.
      • SPN maintenance. If a service logon account changes, remove the SPNs registered on the old account and register them on the new account. Be aware that when a service is installed, a domain administrator can change the account under which your service runs; use Win32 functions or the user interface of the Computer Management administrative tool.
      • ACE maintenance. If a service logon account changes, you need to update ACEs and group memberships to ensure that the service can still access the necessary resources.

    Guidelines for Selecting a Service Logon Account

    A Win32-based service can run in the security context of a local user account, a domain user account, or the LocalSystem account. To decide which account to use, an administrator should install the service with the minimum set of permissions required to perform the service operations. In a typical directory-enabled service, this means the service installer should create a domain user account for the service and grant that account the specific access rights and privileges required by the service at run time. A service should only run under the LocalSystem account if the service requires administrative privileges or must act as part of the operating system on the local computer.

    Be aware that the service installer should, by default, set up the service to run under a domain user account. To run the service under the LocalSystem account, the service installer should query the administrator for permission to do so.

    For more information about descriptions, advantages, and disadvantages of each account type, see:

  • 相关阅读:
    jsp用equals判断两个字符串变量是否相等
    使用session在jsp页面之间传递多维数组,用于实现全局变量的效果
    C++实现对MySQL数据库的连接,以及增删改查
    VS2017项目中使用代码连接MySQL数据库,以及进行数据添加
    VS2017中遇到不存在从string到const char*的转换函数的解决方法
    windows系统转linux系统后磁盘的处理
    redis集群节点重启后恢复
    Jenkins 与Docker/Kubernetes的自动化CI流水(笔记)
    shell的运用 : jenkins 编译 打包前端发布 生产(tomcat)
    云服务器linux系统修改时间和时区
  • 原文地址:https://www.cnblogs.com/chucklu/p/12603499.html
Copyright © 2011-2022 走看看