Шаблон для клиентов WCF Kerberos, где сервер использует учетную запись пользователя

Question

У нас есть клиентское и сервисное приложение WCF (Windows Communication Foundation). Мы используем проверку подлинности Windows с Kerberos.

Проблема заключается в том, что служба может работать под одной из многих учетных записей (может быть, сетевая служба, может быть, определенная учетная запись пользователя - зависит от группы ИТ). Эта учетная запись вряд ли изменится ежедневно, но, возможно, иногда (возможно, каждые несколько месяцев). Кроме того, мы доставляем этот пакет клиент / сервис нескольким группам, и у каждой группы может быть своя собственная учетная запись, на которой они используют службу (это просто означает, что мы не можем сделать индивидуальное решение для одной команды). ).

Теперь причина, по которой вышеприведенный абзац является проблемой, заключается в том, что если служба не работает в учетной записи SYSTEM или NETWORK SERVICE, т. Е. В учетной записи пользователя, то клиент должен указать имя учетной записи пользователя в удостоверении своей личности. конечная точка.

Подробнее об этом ограничении см .: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/feb6bc31-9a4b-4f8d-a887-ef6d2c7abe41 и http://www.vistax64.com/indigo/146204-using-localhost-v-s-environment-machinename.html

Теперь это, по-видимому, усложняет ситуацию, когда ИТ-отдел меняет учетную запись, под которой работает служба. Каков шаблон для обработки этого, если таковой имеется? Как другие люди справились с этим? Одно из решений, о котором я подумал, заключается в том, что администратор отправляет электронное письмо, когда учетная запись пользователя службы изменилась, и на нем есть веб-ссылка на приложение, которое обновляет клиент или файл конфигурации, поэтому клиент ссылается на новую учетную запись пользователя. , Но это кажется хакерским.

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

Кстати, это необходимо разместить на IIS 7.0, если это имеет значение.

Answer 1

Я думаю, вы можете установить для свойства NegotiateServiceCredential значение True, чтобы ваша привязка использовала SPNego вместо хладнокровного Kerberos . Если задано значение true, клиенту не нужно указывать имя участника-службы, и он может подключаться к серверу, на котором установлена ​​учетная запись, не принадлежащая машине.

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

Кроме того, в качестве дополнительной информации: тот факт, что WCF запрашивает в качестве имени участника-службы имя учетной записи, по сути, является интеллектуальным пердением. Клиент должен использовать API DsMakeSpn для создания имени участника-службы из имени службы, хоста и порта. Сервер должен зарегистрировать это имя участника-службы для своего имени при запуске или позволить администратору сделать это с помощью setspn.exe . Именно так они делают все традиционные (с хорошим поведением) сервисы в среде Kerberos / ActiveDirecotry / Windows.

Обновление

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

У меня нет удобной среды для тестирования WCF, но, возможно, вы можете настроить клиенты для запросов правильного имени участника-службы, например YourService/server:port, и вы также зарегистрируете такое же имя участника-службы на стороне сервера. Либо вручную, как упражнение, оставленное администраторам, либо автоматически из вашего сервиса, когда он запускается, и отмените регистрацию при завершении работы. правильный способ сделать это - позволить администраторам сделать это, но на самом деле это такая боль, что большинство служб регистрируют SPN самостоятельно, и вы, вероятно, тоже можете следовать этой практике. Чтобы зарегистрировать имя участника-службы, ваша служба вызывает DsWriteAccountSpn . Запись должна распространяться в AD и реплицироваться между серверами AD, и это как минимум одна из причин, по которой использование службы автоматической регистрации / автоматической отмены регистрации SPN является сомнительной практикой.

Если вы хотите узнать больше о мире чудесных имен SPN и о том, как они могут разрушить ваш день, вы можете прочитать о Как работают публикации и имена участников службы .

Обновление

Я почти уверен, что вы можете использовать любой SPN, какой захотите. Большинство примеров используют имя учетной записи как «UPN» (имя участника-пользователя) вместо SPN, но это только для удобства примеров, поскольку использование истинного SPN может привести к административным проблемам при настройке SPN под учетной записью пользователя (опять же). зачем админам это делать ...). С Переопределение идентификатора службы для аутентификации , соответствующее выделено:

По умолчанию, когда служба настроен на использование Windows учетные данные, элемент, который содержит <userPrincipalName> или <servicePrincipalName> элемент генерируется в WSDL. Если служба работает под локальной системой, LocalService или NetworkService учетная запись, имя участника службы (SPN) генерируется по умолчанию в форма host/<hostname> потому что те учетные записи имеют доступ к компьютеру Данные SPN. Если служба работает под другой учетной записью Windows Фонд связи (WCF) генерирует UPN в форме <username>@<domainName>. Это происходит потому что аутентификация Kerberos требует предоставления UPN или SPN клиенту для проверки подлинности сервис.

Вы также можете использовать инструмент Setspn.exe зарегистрировать дополнительный SPN с учетная запись службы в домене. Вы можете затем использовать SPN в качестве личности услуга . Чтобы загрузить инструмент, см. Windows 2000 Resource Kit Tool: Setspn.exe. Для получения дополнительной информации о инструмент, см. обзор Setspn.

Answer 2

Установите NegotiateServiceCredential и EstablishSecurityContext свойства равными False.