Общая конфигурация и удаленная подготовка

Уолтер Оливер

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

Описание проблемы

Топология подготовки, показанная на следующей схеме, может быть одним из распространенных вариантов использования новой функции общей конфигурации, доступной в СЛУЖБАх IIS 7, которая централизованно использует сетевую папку, а централизованный сервер подготовки будет выполнять операции подготовки в нескольких фермах веб-серверов. Предполагается, что все фермы веб-серверов работают под управлением Windows Server® 2008 R2 с IIS 7.

Типичная топология подготовки

Общую конфигурацию можно легко включить с помощью диспетчера IIS, как показано на следующем снимке экрана.

Набор новых управляемых API был предоставлен в IIS 7 в пространстве имен Microsoft.Web.Administration. API-интерфейсы содержат метод OpenRemote, который обеспечивает удаленное администрирование по сети, как показано на следующей схеме.

В следующем фрагменте кода показано использование OpenRemote для подготовки приложения на другом веб-сервере.

Если для удаленного веб-сервера включена общая конфигурация, при выполнении примера кода возникает следующая ошибка:

Эта проблема не существует, если удаленный веб-сервер использует локальную конфигурацию вместо общей конфигурации.

Отключите общую конфигурацию:

Повторно запустите пример приложения:

Изменение успешно зафиксировано.

Это проблема проверки подлинности с двойным прыжком, вызванная общей конфигурацией на нескольких серверах. Вызов OpenRemote просто удаленно вызывает COM-объект через DCOM. Если конфигурация не настроена локально, COM-объект попытается выполнить двойной прыжок, который не разрешен при использовании COM. Помните, что это происходит только в операции записи в общую конфигурацию.

При выполнении операции чтения система конфигурации подчеркивания использует учетные данные, хранящиеся в файле redirection.config, для проверки подлинности на удаленном сервере общей сетевой папки, что не будет иметь этой проблемы двойного прыжка. При операциях записи конфигурация подчеркивания использует маркер безопасности вызывающего объекта для выполнения операций, которые маркер безопасности является недопустимым на удаленном сервере общей сетевой папки.

Методы обхода проблемы

Вариант 1. Изменение конфигурации DCOM для COM-объекта конфигурации с помощью указанной учетной записи

Чтобы обойти проблему двойного прыжка с COM-объектом конфигурации, необходимо изменить конфигурацию DCOM, чтобы использовать указанную учетную запись вместо контекста безопасности вызывающей стороны, чтобы включить проверку подлинности COM-объекта конфигурации на удаленном сервере общей сети с указанными учетными данными.
Com-объект конфигурации IIS 7 — ahadmin можно найти в конфигурации DCOM с помощью служб компонентов на удаленном веб-сервере, как показано на следующей схеме:

Щелкните правой кнопкой мыши узел ahadmin и выберите свойства..., перейдите на вкладку Удостоверение, измените параметр на This User (Этот пользователь) вместо Запускающий пользователь и укажите учетную запись пользователя со следующими разрешениями:

1. У вас есть разрешения на изменение общих файлов конфигурации на сервере общей сетевой папки.
2. Разрешение на чтение для redirection.config файла, хранящегося в system32\inetsrv\config
3. Член группы локальных администраторов, в противном случае вы не сможете расшифровать исключение.

Нажмите кнопку ОК.

После изменения повторно запустите пример приложения, чтобы оно работало успешно.

Тестовое приложение подготовлено правильно.

Использование указанной учетной записи для COM-объекта конфигурации может привести к дополнительным угрозам безопасности (т. е. любые пользователи могут изменять конфигурацию при условии, что у них есть разрешение на вызов COM-объекта). Чтобы снизить риски безопасности, настройте только один веб-сервер в ферме веб-серверов, используя этот параметр для подготовки, и настройте брандмауэр, чтобы разрешить доступ к серверу только определенным IP-адресам.

**Предупреждение системы безопасности**

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

Вариант 2. Использование примера подхода служб размещения

Альтернативный вариант — не использовать OpenRemote через вызов DCOM и вместо этого создать службу, например Пример кода служб размещения, который представляет собой набор веб-служб, построенных на основе WCF (Windows Communication Foundation), на одном из веб-серверов в веб-ферме, как показано на следующей схеме:

Вы можете использовать службу Windows для размещения служб, если у вас есть проблемы с размещением в IIS 7. Веб-служба создана на основе API-интерфейсов Microsoft.Web.Administration и обеспечивает лучший вариант интеграции, и, кроме того, нет необходимости открывать брандмауэр в соответствии с требованиями OpenRemote.

Вопросы безопасности

Служба должна быть защищена, чтобы разрешить только авторизованным и прошедшим проверку подлинности пользователям вызывать службу.

Вариант 3. Использование инструментария WMI

Еще один способ избежать проблемы двойного прыжка — использовать службу WMI, как показано на следующей схеме.

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