Минимальные права, необходимые для запуска службы windows в качестве учетной записи домена [закрыто]

кто-нибудь знает, какие минимальные права мне нужно будет предоставить учетной записи пользователя домена для запуска службы windows в качестве этого пользователя?

для простоты предположим, что служба не делает ничего сверх запуска, остановки и записи в журнал событий "приложение", т. е. нет доступа к сети, нет пользовательских журналов событий и т. д.

Я знаю, что могу использовать встроенные учетные записи Service и NetworkService, но возможно, что я не смогу их использовать из-за сетевых политик.

4 ответов


два варианта:

  1. измените свойства сервиса и установите вход пользователя. Соответствующее право будет автоматически присвоено.

  2. установите его вручную: перейдите в Администрирование - > Локальная политика безопасности - > Локальные политики - > назначение прав пользователя. Отредактируйте пункт "Войти как служба" и добавьте туда пользователя домена.


Я знаю, что учетная запись должна иметь права "вход в качестве службы" привилегии. Кроме этого, я не уверен. Краткая ссылка для входа в систему в качестве службы может быть найдена здесь, и есть много информации о конкретных привилегиях здесь.


"BypassTraverseChecking" означает, что вы можете напрямую обращаться к любому подкаталогу глубокого уровня, даже если у вас нет всех промежуточных привилегий доступа к каталогам между ними, т. е. ко всем каталогам выше него на корневом уровне .


Спасибо за ссылки, Крис. Я часто задавался вопросом о конкретных последствиях привилегий, таких как" BypassTraverseChecking", но никогда не удосуживался их искать.

У меня были интересные проблемы с запуском службы и обнаружилось, что у нее нет доступа к ее файлам после первоначальной установки администратором. Я думал, что ему нужно что-то в дополнение к входу в систему в качестве службы, пока я не нашел файл вопрос.

  1. отключен простой общий доступ к файлам.
  2. временно личного кабинета администратора.
  3. используется учетная запись службы, чтобы взять на себя ответственность за файлы.
  4. удалить учетную запись в группу Администраторы.
  5. перезагрузка.

во время Take Ownership необходимо было отключить наследование разрешений из родительских каталогов и применить разрешения рекурсивно вниз дерево.

не удалось найти "дать ownership", чтобы избежать временного превращения учетной записи службы в администратора.

во всяком случае, я думал, что опубликую это на случай, если кто-то еще пойдет по той же дороге, по которой я искал проблемы политики безопасности, когда это были просто права файловой системы.