Реализуемая мной служба будет работать на контроллере домена., поэтому я бы хотел, чтобы у него были минимальные привилегии. В идеале он должен работать просто как локальная служба. Однако он должен уметь:
Очевидно, что добавление локальной службы к этим группам - не лучший подход. Запуск службы от имени виртуальной учетной записи службы, созданной для нее, позволит ей получить доступ к сети с идентификатором компьютера, что также нежелательно. Так что я бы хотел запустить его как локальную службу с ненулевым типом SID, тем самым передавая ему привилегии, предоставленные VSA.
У меня возникли проблемы с добавлением VSA службы в указанные выше группы. Я подозреваю, что это потому, что VSA является локальным (и существует только в контроллере домена), а группы являются группами домена. Является ли это возможным?
Групповые управляемые учетные записи служб могут оказаться полезными (заменяя VSA), если их нужно создавать вручную.
Какой правильный подход к настройке службы для работы только с указанными разрешениями, когда для развертывания нет предварительных условий (без создания GMSA)?
Также приветствуются ответы, относящиеся к конкретным группам.
На контроллере домена у вас нет базы данных «локальных учетных записей» и нет групп локальных серверов.
Локальные группы называются «локальными доменами» и могут использоваться в любом месте домена (в соответствии с правилами домена о том, как группы могут быть вложены). AD - это «база данных локальных учетных записей» DC.
Лучшее решение здесь - НЕ запустить его на самом DC. Контекст SYSTEM на контроллере домена имеет полный доступ ко всему в AD. Это возможная угроза безопасности, ожидающая своего часа.