6. Отметьте Include inheritable permissions from this object’s parent and Replace all child object permissions with inheritable permissions from this object и дважды нажмите OK.

Теперь настройки безопасности директории Default установлены верно. Попробуйте залогиниться заново.

Service Logon Accounts

A service, like any process, has a primary security identity that determines the granted access rights and privileges for local and network resources. This security identity, or security context, also determines the potential the service has for damaging local and network resources.

The security context for a Microsoft Win32 service is determined by the logon account that is used to start the service. This section discusses programming issues and best practices relating to the service logon account used by Win32 services, with a focus on directory-enabled services. This section includes the following topics:

• About Service Logon Accounts—An overview of service logon accounts and security context programming issues for a Win32 service.
• Guidelines for Selecting a Service Logon Account for a Win32 service.
• Setting up a Service’s User Account.
• Installing a Service on a Host Computer and specifying the service logon account.
• Granting Logon as Service Right on the Host Computer—Granting the service’s user account the logon as a service right on the host computer.
• Testing Whether Running on a Domain Controller—Detecting at installation time whether the service instance is being installed on a domain controller.
• Granting Access Rights to the Service Logon Account—Setting and maintaining ACEs and group memberships to ensure that the system will grant the running service access to the necessary local and network resources.
• Changing the Password on a Service’s User Account—Changing the password on a service’s user account, and at the same time updating the password registered with the service control manager on each host server on which the service is installed.
• Mutual Authentication Using Kerberos—Maintaining service principal name (SPN) registration on the directory object associated with the logon account of each instance of your service. SPNs enable clients to authenticate a service using Kerberos mutual authentication.
• Converting Domain Account Name Formats—For example, converting a distinguished name to Domain**\**UserName format, and vice versa.

Вход в качестве службы Log on as a service

Область применения Applies to

В этой статье описываются рекомендации, рекомендации по расположению, значениям, **** управлению политиками и безопасности для параметра политики безопасности «Вход в качестве службы». This article describes the recommended practices, location, values, policy management, and security considerations for the Log on as a service security policy setting.

Справочные материалы Reference

Этот параметр политики определяет, какие учетные записи служб могут регистрировать процесс как службу. This policy setting determines which service accounts can register a process as a service. Запуск процесса под учетной записью службы не учитывает необходимость вмешательства человека. Running a process under a service account circumvents the need for human intervention.

Константа: SeServiceLogonRight Constant: SeServiceLogonRight

Возможные значения Possible values

• Определяемый пользователей список учетных записей User-defined list of accounts
• Не определено Not Defined

Рекомендации Best practices

• Свести к минимуму количество учетных записей, которые имеют это право пользователя. Minimize the number of accounts that are granted this user right.

Location Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Значения по умолчанию Default values

По умолчанию этот параметр является сетевой службой на контроллерах домена и сетевой службой на автономных серверах. By default this setting is Network Service on domain controllers and Network Service on stand-alone servers.

В следующей таблице приведены фактические и действующие значения по умолчанию для этой политики. The following table lists the actual and effective default policy values. На странице свойств политики также перечислены значения по умолчанию. The policy’s property page also lists default values.

Управление политикой Policy management

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой. This section describes features, tools, and guidance to help you manage this policy.

Для активации этого параметра политики не требуется перезагрузка компьютера. A restart of the computer isn’t required for this policy setting to be effective.

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись. Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.

Групповая политика Group Policy

Если учетная запись пользователя подчиняется обеим политикам, то этот параметр политики «Запретить в качестве службы» переоменовывает этот параметр политики. The policy setting Deny logon as a service supersedes this policy setting if a user account is subject to both policies.

Параметры групповой политики применяются в следующем порядке, что перезапишет параметры на локальном устройстве при следующем обновлении групповой политики: Group Policy settings are applied in the following order, which will overwrite settings on the local device at the next Group Policy update:

1. Параметры локальной политики Local policy settings
2. Параметры политики сайта Site policy settings
3. Параметры политики домена Domain policy settings
4. Параметры политики подразделения OU policy settings

Вопросы безопасности Security considerations

В этом разделе описывается, как злоумышленник может использовать функцию или ее конфигурацию. This section describes how an attacker might exploit a feature or its configuration. В нем объясняется меры противодействия. It explains the countermeasure. Кроме того, он решает возможные отрицательные последствия противодействия. And it addresses the possible negative consequences of the countermeasure.

Уязвимость Vulnerability

Право входа в систему как пользователя службы позволяет учетным записям запускать сетевые службы или службы, которые непрерывно работают на компьютере, даже если никто не входит в консоль. The Log on as a service user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. Риск снижается, так как устанавливать и настраивать службы могут только пользователи с административными привилегиями. The risk is reduced because only users who have administrative privileges can install and configure services. Злоумышленник, который уже достиг этого уровня доступа, может настроить службу для запуска с помощью учетной записи Local System. An attacker who has already reached that level of access could configure the service to run with the Local System account.

Противодействие Countermeasure

По определению учетная запись сетевой службы имеет право входа в качестве пользователя службы. By definition, the Network Service account has the Log on as a service user right. Это право не предоставляется с помощью параметра групповой политики. This right isn’t granted through the Group Policy setting. Свести к минимуму количество других учетных записей, которые имеют это право пользователя. Minimize the number of other accounts that are granted this user right.

Service User Accounts

Each service executes in the security context of a user account. The user name and password of an account are specified by the CreateService function at the time the service is installed. The user name and password can be changed by using the ChangeServiceConfig function. You can use the QueryServiceConfig function to get the user name (but not the password) associated with a service object. The service control manager (SCM) automatically loads the user profile.

When starting a service, the SCM logs on to the account associated with the service. If the log on is successful, the system produces an access token and attaches it to the new service process. This token identifies the service process in all subsequent interactions with securable objects (objects that have a security descriptor associated with them). For example, if the service tries to open a handle to a pipe, the system compares the service’s access token to the pipe’s security descriptor before granting access.

The SCM does not maintain the passwords of service user accounts. If a password is expired, the logon fails and the service fails to start. The system administrator who assigns accounts to services can create accounts with passwords that never expire. The administrator can also manage accounts with passwords that expire by using a service configuration program to periodically change the passwords.

If a service needs to recognize another service before sharing its information, the second service can either use the same account as the first service, or it can run in an account belonging to an alias that is recognized by the first service. Services that need to run in a distributed manner across the network should run in domain-wide accounts.

You can specify one of the following special accounts instead of specifying a user account for the service:

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.