Log on as a service
Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8
This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this 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.
This policy setting is supported on versions of Windows that are designated in the Applies To list at the beginning of this topic.
Possible values
User-defined list of accounts
Best practices
Location
GPO_name\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 for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
Server type or GPO
Default Domain Policy
Default Domain Controller Policy
Stand-Alone Server Default Settings
Domain Controller Effective Default Settings
Member Server Effective Default Settings
Client Computer Effective Default Settings
Operating system version differences
There are no differences in the way this policy setting works between the supported versions of Windows that are designated in the Applies To list at the beginning of this topic.
The default changed in Windows ServerВ 2008В R2 and WindowsВ 7 from Not defined in that only the Network Service account has this right by default. Any service that runs under a separate user account must be assigned this user right.
Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not 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 computer at the next Group Policy update:
Local policy settings
Site policy settings
Domain policy settings
OU policy settings
Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
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 by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained 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 is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.
Deny log on as a service
Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8
This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for this policy setting.
Reference
This policy setting determines which users are prevented from logging on to the service applications on a computer.
A service is an application type that runs in the system background without a user interface. It provides core operating system features, such as web serving, event logging, file serving, printing, cryptography, and error reporting.
This policy setting is supported on versions of Windows that are designated in the Applies To list at the beginning of this topic.
Possible values
User-defined list of accounts
Best practices
When you assign this user right, thoroughly test that the effect is what you intended.
Within a domain, modify this setting on the applicable Group Policy Object (GPO).
Location
GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
Server type or GPO
Default Domain Policy
Default Domain Controller Policy
Stand-Alone Server Default Settings
Domain Controller Effective Default Settings
Member Server Effective Default Settings
Client Computer Effective Default Settings
Operating system version differences
There are no differences in the way this policy setting works between the supported versions of Windows that are designated in the Applies To list at the beginning of this topic.
Policy management
This section describes features and tools available to help you manage this policy.
A restart of the computer is not 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.
For information about configuring a service, see Configure How a Service Is Started.
Group Policy
On a domain-joined computer, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting.
This policy setting might conflict with and negate the Log on as a service setting.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
Local policy settings
Site policy settings
Domain policy settings
OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
Vulnerability
Accounts that can log on to a service application could be used to configure and start new unauthorized services, such as a keylogger or other malicious software. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative rights can install and configure services, and an attacker who has already attained that level of access could configure the service to run by using the System account.
Countermeasure
We recommend that you not assign the Deny log on as a service user right to any accounts. This is the default configuration. Organizations that are extremely concerned about security might assign this user right to groups and accounts when they are certain that they will never need to log on to a service application.
Potential impact
If you assign the Deny log on as a service user right to specific accounts, services may not start and a denial-of-service condition could result.
Group Managed Service Accounts в Windows Server 2012
Технология управляемых служебных записей (Managed Service Accounts – MSA) впервые была представлена в Windows Server 2008 R2 и предназначена для автоматического управления (смены) паролей служебных (сервисных) учетных записей. Благодаря использованию механизма Managed Service Accounts можно существенно снизить риск компрометации системных учетных записей, из-под которых запущены системные службы(не секрет, что существует большое количество утилит, позволяющих извлечь пароли локальных пользователей из LSASS).
Для учетных записей MSA генерируется пароль длиной 240 символов, из которых половина – английские буквы, другая половина – служебные символы. Пароль такой учетной записи меняется автоматически (по-умолчанию каждые 30 дней) и не хранится на локальной системе
Основным недостатком MSA является возможность использования подобной служебной записи только на одном компьютере. Это означает, что служебные учетные записи MSA не могут работать с кластерными и NLB службами (веб-фермы), которые работают одновременно на нескольких серверах и используют одну учетную запись и пароль.
Для преодоления указанного недостатка Microsoft в Windows Server 2012 добавила функционал групповых управляемых учетных записей служб (gMSA — Group Managed Service Accounts). Такие учетные записи можно одновременно использовать на нескольких серверах, чтобы все экземпляры службы использовали одну и ту же учетную запись, например в службе балансировки нагрузки (NLB), кластерных службах и т.п.
Требования gMSA :
Чтобы воспользоваться возможностями gMSA, нужно, чтобы инфраструктура соответствовала следующим требованиям:
- Уровень схемы AD — Windows Server 2012 (как ее обновить описано здесь).
- Контроллер домена Windows Server 2012 (и выше) со службой Microsoft Key Distribution Service (служба распространения ключей) – именно это служба отвечает за генерацию паролей
- PowerShell модуль для управления Active Directory
- В качестве клиентов могут использоваться Windows Server 2012/2012 R2 и Windows 8/8.1
- Служба, использующая gMSA должна быть совместима с этим типом аккаунтов (должно быть указано в документации). На данный момент gMSA поддерживают: SQL Server 2008 R2 SP1, 2012;IIS; AD LDS; Exchange 2010/2013
Создаем KDS ключ
Прежде, чем приступить к созданию учетной записи gMSA, необходимо выполнить разовую операцию по созданию корневого ключа KDS (KDS root key). Для этого на контроллере домена с правами администратора выполните команду (служба Microsoft Key Distribution Services должна быть установлена и включена):
В этом случае ключ будет создан и доступен через 10 часов, после окончания репликации.
Проверим, что корневой ключ KDS создался успешно:
Создаем учетную запись gMSA
Создадим новую учетную запись gMSA командой:
Где, gmsa1 – имя создаваемой учетной записи gMSA
dc1.winitpro.ru – имя DNS сервера
gmsa1Group – группа Active Directory, в которую включены все системы, которые будут использовать эту групповую учетную запись (группа должна быть создана предварительно)
После выполнения команды нужно открыть консоль ADUC (Active Directory Users and Computers) и проверить, что в контейнере (OU) Managed Service Accounts появилась советующая учетная запись (по умолчанию этот контейнер не отображается, чтобы его увидеть, нужно в меню View оснастки включить опцию Advanced Features) 
Установка gMSA на сервере
Подключим модуль Powershell для поддержки среды Active Directory:
Далее нам нужно установить управляемую учетную запись на сервера, на которых она будет использоваться (из-под этой учетки в дальнейшем будет запущен некий сервис). В первую очередь нужно проверить, что этому серверу разрешено получать пароль учетной записи gMSA из Active Directory. Для этого его учетная запись должна состоять в указанной при создании доменной группе (в нашем случае gmsa1Group). Установим запись gmsa1 на данном сервере:
Проверить, что учетная групповая сервисная запись установлена корректно можно так (для Windows PowerShell 4.0):
Если команда вернет True – все настроено правильно.
Далее в свойствах службы укажем, что она будет запускаться их под учетной записи gMSA. Для этого на вкладке Log on нужно выбрать This account и указать имя сервисной учетной записи. В конце имени обязательно указывается символ $, пароль указывать не нужно. После сохранения изменений службу нужно перезапустить.
Сервисной учетной записи автоматически будут предоставлены права «Log On As a Service».
«Тонкая» настройка gMSA
Периодичность смены пароля можно изменить (по умолчанию 30 дней):
Учетную запись gMSA можно использовать и в задачах планировщика. Тонкий нюанс в том, что задание можно настроить только через PowerShell.
Аргумент «-LogonType Password» означает, что пароль для этой gMSA учетной записи будет получен с контроллера домена.