Одна из самых больших проблем, с которыми мы сталкиваемся при автоматизации развертывания приложений, - это идея о том, что запуск IIS AppPools и Windows Services под учетными записями доменных служб является «лучшей практикой». К сожалению, эта передовая практика иногда вызывает проблемы с развертыванием, так как либо нам нужно быстро подготовить новую учетную запись службы уровня домена, либо, когда у нас есть учетная запись, теперь нам нужно управлять учетными данными.
У меня был отличный разговор о том, чтобы не делать учетные записи служб на уровне домена требованием и эффективно использовать один из двух подходов:
В обоих случаях кажется, что проще управлять либо добавлением учетной записи в соответствующую группу / роль, либо даже созданием новой локальной учетной записи, чем создавать новую учетную запись уровня домена и управлять этими учетными данными.
Мы надеемся, что это снизит нагрузку на управление для команд ActiveDirectory, Sql Server и операций, поскольку больше нет управления паролями.
На самом деле мы еще не смогли реализовать это на практике. Я исхожу из опыта разработки, поэтому мне любопытно, во многих случаях этот подход может пойти не так? Можем ли мы действительно избавиться от учетных записей служб на уровне домена с помощью этого направления?
Буду признателен за любые мысли от всех, кто встал на этот путь!
Спасибо!
Зак
ОБНОВИТЬ
Раньше, поскольку команды разработчиков приложений не хотели хранить пароли для учетных записей служб, а нам было все равно, что они собой представляют (не так ли?), Мы предоставили нашей команде ActiveDirectory утилиту, которая создает хэш пароля. Итак, когда нам требовалась учетная запись службы, мы отправляли запрос, и они отвечали хешированным паролем.
В наших сценариях развертывания (которыми владела команда разработчиков) везде, где мы использовали пароль, мы фактически использовали хэш. Платформа развертывания знала, как декодировать этот хэш на лету при создании ресурсов.
Думаю, @Tom указал мне в правильном направлении. Windows Server 2008 R2 представила идею Управляемые учетные записи служб и Учетные записи виртуальных служб. Похоже, эта функция - это то, что я искал, чтобы избавиться от управления паролями.
Почитайте пост Скотта Форсайта Управляемые учетные записи служб (MSA) и виртуальные учетные записи и TechNet Учетные записи служб: пошаговое руководство Чтобы получить больше информации.
Вот параллельное сравнение Управляемые учетные записи служб и виртуальные учетные записи.
Ахиллесова пята управляемых учетных записей служб заключается в том, что они ограничено 1 компьютером по какой-то причине? Это не позволяет мне масштабироваться и заставляет меня вернуться к традиционной модели учетной записи службы, где я отвечаю за учетную запись службы. Если мне нужно это сделать, то добавление локальных учетных записей (со случайными паролями или даже учетной записью компьютера) в конкретную группу AD и сопоставление их с ролями Sql по-прежнему работает? Мне бы очень хотелось, чтобы кто-нибудь с опытом эксплуатации помог мне понять, почему это плохой.
Я не понимаю последствий запрета доступа к сети для учетной записи компьютера, пока я защищаю этот узел другими способами. Например. разрешить только исходящие служебные вызовы к известным конечным точкам через брандмауэр или каким-либо другим способом?
В остальном управляемые учетные записи служб и виртуальные учетные записи кажутся функционально эквивалентами того, что я искал.
Я считаю, что Server 2008 предоставил механизм для управления учетными записями служб и автоматической смены их паролей.
Изменить: это может быть конкретно с 2008 R2. Кажется, я помню, как читал это, когда узнал об улучшениях схемы.