☰

Должны ли все службы ADCS работать под одной и той же учетной записью на одном сервере?

tag-icon • tag-icon ad-certificate-services service-accounts
Должны ли все службы ADCS работать под одной и той же учетной записью на одном сервере?

При развертывании ADCS в документации Microsoft рекомендует использовать учетные записи служб для служб, составляющих ADCS. Проблема в том, что в ней не рассматривается, следует ли управлять ими по отдельности, могут ли они совместно использовать хост, а также не рассматривается потеря доступа из удаленного диспетчера серверов из-за делегирования Kerberos.

Я узнал, как это исправить некоторое время назад, потому что это та же самая проблема, когдаАФС*развертывается: управление компьютером перехватывается учетной записью службы, но,как вы, вероятно, знаете,его можно вернуть, просто добавив псевдонимы Active Directory (CNAME) к учетной записи машины. например:

        …если бы СА назывался LOCKSMITH…

netdom computername locksmith /add:ceslocksmith.domain.tld
netdom computername locksmith /add:ceplocksmith.domain.tld
netdom computername locksmith /add:nedeslocksmith.domain.tld

        …или, может быть, даже поддомены; (я никогда не пробовал эту идею)

netdom computername locksmith /add:ces.locksmith.domain.tld
…

Поэтому мне было интересно,еслиЯ добавляю псевдонимы для каждой из учетных записей служб, которые может использовать ADCS (CES, CEP, NDES). Я могу запустить каждую из них в соответствии с рекомендацией, но на одной и той же машине —возможно, это противоречит лучшим практикам, но вы знаете— за исключением того, что я нашел эту штуку на каком-то форуме, где говорилось, чтонесколько экземпляров CES(я предполагаю, что на ферме) все должно работать стот же сервисный аккаунт. О других услугах не упоминалось. Но должны ли они также использовать одну и ту же учетную запись, или это нормально для отдельных услугпривязан кодинокийПредприятие CAчтобы каждый запускался под своей собственной учетной записью?

Спасибо.

*: на самом деле это хуже для ADFS, потому что в течение нескольких лет документация ошибочно указывала на использование неправильного Kerberos service/PRINCIPAL. Она указывает host, вместо httpслужбы. Предоставление контроля надhttpк учетной записи в большинстве случаев блокирует вас от удаленного администрирования/PowerShell удаленного взаимодействия, но передача управления хостом от учетной записи машины оставляет ее без домена. Хуже того, это повторяется дословноMVPи другие в своих блогах.

решение1

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

Коннектор NDES (для SCEP) не должен быть установлен на сервере CA, выпускающем сертификаты, поэтому это не входит в уравнение. Он должен работать как собственная учетная запись службы с соответствующими правами «Выпуск сертификата», делегированными CA, плюс другие требования, согласнодокументация.

Для CES/CEP вы устанавливаете их только по мере необходимости - например, для кросс-доменных или не присоединенных к домену машин/внешних пользовательских регистраций сертификатов. Лично я счастливее, если они не на сервере CA, но выможетРазверните их там. По умолчанию они используют идентификатор пула приложений для веб-службы, но вы можете (и должны) изменить его на учетную запись пользователя домена. Также обратите внимание, что вы можете использовать (g)MSA для запуска служб.Эта документациядовольно старый, но по-прежнему самый полный.

В документации отмечается, что если вы устанавливаете CES/CEP на CA, вы можете столкнуться со следующей проблемой. Вот почему я лично запускал бы эти службы в другом месте,еслиони обязательны.

Если другие службы http/https с аутентификацией Kerberos работают на том же хосте, что и веб-служба политики регистрации сертификатов или веб-служба регистрации сертификатов, настроенная для аутентификации Kerberos, могут возникнуть сбои регистрации из-за конфликта SPN. Решение заключается в настройке всех служб для запуска с использованием одной и той же учетной записи пользователя.

Наконец, неясно, какой документации вы следуете или какую версию ADCS вы развертываете, но не забудьте защитить серверы CA от атак NTLM-ретранслятора, согласноКБ5005413. В идеале это означает отключение аутентификации NTLM на контроллерах домена (довольно сложно в большинстве корпоративных сред) или, в качестве альтернативы, на каждом сервере CS (т. е. серверах CA или CES). Минимальные обходные пути требуют https и настраивают расширенную защиту для аутентификации (EPA) на веб-сервисах регистрации.

Связанный контент