Я создаю групповую политику для нового домена, на который мы переходим. В нашей текущей среде настройки Войти как услуга установлен на Сервер Уровень OU - у которого есть около сотни учетных записей служб в этом поле для доступа к этому праву.
Я хотел бы установить это ниже в нашей древовидной структуре OU (мы разделяем серверы в зависимости от приложения, которое они запускают), но некоторые наши внутренние сотрудники вообще не хотят устанавливать эту политику. IE: не проверять параметр в групповой политике и позволять локальным серверам решать, какие учетные записи помещены в его локальную политику для этого параметра. Наша команда внутренней безопасности хочет, чтобы он был установлен, как и я, но пара людей, которые не хотят, чтобы он был установлен, включает архитектора - отсюда конфликт.
Я проконсультировался со службой поддержки Microsoft Premier (у которой не было официального ответа для меня), внутренним персоналом, внешним ИТ-персоналом и часами интернет-исследований, но я не могу найти никакой информации о том, следует ли вообще устанавливать эту политику. Я склонен управлять этим через GPO, чтобы его можно было легко проверять и управлять из одного места (наша компания время от времени проходит различные внешние аудиты).
Страница ресурсов Microsoft: https://technet.microsoft.com/en-us/library/dn221981.aspx это единственная информация, которую я могу найти об этом, но он говорит минимизировать количество учетных записей, которым предоставлено это право пользователя. Мне это кажется немного двусмысленным ...
Может кто-нибудь сказать мне, что они думают об этих настройках?
Статья, которую вы связали дает объяснение того, какие права Войти как услуга обеспечивает:
Право «Вход в качестве пользователя службы» позволяет учетным записям запускать сетевые службы или службы, которые постоянно работают на компьютере, даже если никто не вошел в систему на консоли.
Короче говоря, вы хотите предоставить это право только тем учетным записям, которые в нем нуждаются - по умолчанию это учетные записи локальной системы, локальной службы и сетевой службы, потому что это то, под чем по умолчанию работают службы.
Если вы хотите запустить службу в другом контексте безопасности (например, создаваемую вами учетную запись службы), вы хотите предоставить эту учетную запись службы Войти как услуга права, чтобы он мог запускать вашу службу без необходимости входа пользователя в систему. В статье, на которую вы ссылаетесь, в качестве примеров предоставляются IIS и ASP.NET, где это право предоставляется дополнительным учетным записям; это относится и к сторонним программам, которые также работают как службы.
Если вы не хотите запускать каждую службу как SYSTEM или NetworkService, вы должны настроить учетные записи служб для отдельных служб и назначить им это Войти как услуга право. Основное преимущество использования учетных записей служб таким образом состоит в том, что если ваша служба скомпрометирована, она будет работать в контексте безопасности учетной записи, в которой она запущена, а не в контексте безопасности уровня SYSTEM, который есть у SYSTEM и NetworkService.
Таким образом, рекомендуется назначать это право только учетным записям, под которыми работают службы, и запускать отдельные службы под учетными записями служб, настроенными в соответствии с принцип наименьших привилегий (дайте им только разрешения, необходимые для запуска; не давайте им права администратора или SYSTEM). Я бы добавил, что управление этим с помощью GPO - более безопасный подход. Если он контролируется локально на каждом сервере, то любой, кто получает права администратора на сервере, может контролировать, какие учетные записи могут запускать службы на этом сервере, тогда как для его обеспечения через GPO требуется получение соответствующих прав домена на уровне домена.
«Это право пользователя определяется в объекте групповой политики контроллера домена по умолчанию (GPO) и в локальной политике безопасности рабочих станций и серверов. По умолчанию ни одна учетная запись не имеет права входа в систему в качестве службы».
https://technet.microsoft.com/en-us/library/cc957141.aspx
Учетные записи, которых нет в этом списке, не должны иметь возможность входить в систему в качестве службы, поэтому, если вы очистите список, ваши службы с учетными записями служб больше не смогут запускаться.
Я обычно создаю группу учетных записей службы и помещаю ее в политику. Это уменьшает количество раз, когда мне нужно вносить изменения в саму политику. И, как вы сказали, гораздо проще провести аудит, чем позволить ему настроить сервер на сервер.