Задний план
У меня есть случай, когда компьютер разработчика находится в среде, где ИТ-отдел настроил принудительную групповую политику для политики назначения прав пользователей «Вход в качестве службы». Политика настроена как принудительная и недоступная для редактирования, и поэтому полностью заменяет локальные настройки.
Поскольку это компьютер разработки с установленной версией SQL Server Developer Edition и работающим IIS, это право пользователя используется как учетными записями SQL Server по умолчанию, так и виртуальными учетными записями для пулов приложений (которые динамически добавляются / удаляются в / из этого право пользователя при добавлении или удалении пула приложений). Без учетной записи службы SQL Server, добавленной к этому праву пользователя, SQL Server даже не запустится.
Лично мне кажется странным наличие принудительного объекта групповой политики, запрещающего поведение по умолчанию для прав локального пользователя. ИТ-отдел добавил кучу административных сервисных групп, а также кучу специальных групп пользователей, которые, похоже, были добавлены в качестве обходного пути для других отделов разработчиков в организации. С точки зрения безопасности, я также задаюсь вопросом, почему другие отделы разработки должны получать доступ «Вход в качестве службы» на моем компьютере, когда им действительно нужен этот доступ к своим локальным компьютерам.
Вопросы
Можно ли развернуть объект групповой политики таким образом, чтобы он только добавлял параметры сервера к локальным параметрам, а не заменял их?
Можно ли развернуть объект групповой политики и оставить его редактировать локальный пользователь?
Можно ли развернуть объект групповой политики другим способом, чтобы он не влиял на локальные настройки?
Будет ли это работать с обходным путем, когда группа пользователей добавляется в объект групповой политики сервера и где локальный администратор на компьютере разработчика имеет доступ для администрирования и добавления учетных записей локальных служб в эту группу?
Будет ли метод № 4 работать с виртуальными учетными записями из пула приложений или им нужен прямой доступ к правам пользователя, а не неявно через группу пользователей?
Каковы лучшие практики в отношении объектов групповой политики для права пользователя «Вход в качестве службы»? Спонтанно кажется странным обращаться с пользователем так, как это делает этот ИТ-отдел.
Окружающая среда
Машина разработчика: Windows 8.1 Enterprise Eng
Сервер AD: domainControllerFunctionality: 5 = (WIN2012); domainFunctionality: 4 = (WIN2008R2); forestFunctionality: 4 = (WIN2008R2);
Не знаю, указывает ли это на Win2008R2 или Win2012-сервер.
Был бы очень признателен как за подробную информацию о возможностях развертывания GPO, так и за передовой опыт и творческие решения конкретной проблемы!
Каждый GPO является «принудительным».
Ответ на вопросы от 1 до 3 - решительное НЕТ.
В этом случае я бы попросил их создать пользователей для служб SQL Server. Этих пользователей следует добавить в группу, которой разрешено запускать в качестве службы, а затем настроить локальную машину SQL для работы с этими учетными данными.
У Microsoft есть руководство по угрозам и контрмерам. Поищи это. Я вставлю сюда. Я использую мобильный телефон, так что простите за неправильное форматирование.
Войти как сервис
Этот параметр политики определяет, какие учетные записи служб могут регистрировать процесс как службу. В Windows Server 2008 R2 и Windows 7 только учетная запись сетевой службы имеет это право по умолчанию. Любая служба, которая работает под отдельной учетной записью пользователя, должна иметь это право.
Возможные значения: определенный пользователем список учетных записей / неопределенная уязвимость.
Уязвимость. Вход в качестве службы позволяет учетным записям запускать сетевые службы или службы, которые постоянно работают на компьютере, даже если никто не вошел в систему на консоли. Риск снижается за счет того, что только пользователи с правами администратора могут устанавливать и настраивать службы. Злоумышленник, который уже достиг такого уровня доступа, может настроить службу для работы с учетной записью локальной системы.
Контрмера: по определению, учетная запись сетевой службы имеет право «Вход в систему в качестве пользователя службы». Это право не предоставляется параметром групповой политики. Вы должны минимизировать количество других учетных записей, которым предоставлено это право пользователя.
Возможное влияние: на большинстве компьютеров ограничение права «Вход в качестве пользователя службы» для встроенных учетных записей «Локальная система», «Локальная служба» и «Сетевая служба» является конфигурацией по умолчанию и не оказывает отрицательного воздействия. Однако, если вы установили дополнительные компоненты, такие как ASP.NET или IIS, вам может потребоваться назначить право «Вход в качестве пользователя службы» для дополнительных учетных записей, которые требуются для этих компонентов. IIS требует, чтобы это право пользователя было явно предоставлено учетной записи пользователя ASPNET.