Добро пожаловать! В первой части этого рассказа мы успешно настроили клиента WCF и службу, размещенную на IIS, для связи через MSMQ на одном компьютере. Но мы только наполовину сделали. Как вы помните, наша цель здесь — развернуть клиент, службу и очереди на разных компьютерах. Мы также хотим защитить конфигурацию, чтобы только или клиенту разрешалось отправлять сообщения в очередь.
Прежде чем мы погрузимся, быстрый отказ от ответственности. Как я упоминал в первой статье, на момент написания статьи было очень мало информации о том, как правильно настроить этот сценарий. Таким образом, нам пришлось использовать много проб и ошибок. Хотя я надеюсь, что все советы в этой статье являются правильными и полезными, имейте в виду, что у меня нет времени или ресурсов для тестирования всего в чистой среде. Если какой-либо из этих советов окажется неверным или я пропустил что-то важное, пожалуйста, дайте мне знать, и я исправлю статью.
Переход на несколько серверов без безопасности
Следующим этапом этого пути является запуск всех компонентов на их собственных серверах, как показано на диаграмме ниже (да, это тот же самый компонент, который я включил в часть 1). Так как заставить все работать немного сложнее, мы продолжим предпринимать шаги, чтобы не переходить на аутентифицированные или транзакционные сообщения.
[Img_assist | NID = 4157 | название = | убывание = | ссылка = нет | Align = нет | ширина = 640 | Высота = 323]
Установите необходимые компоненты и приложения
Для начала убедитесь, что у вас есть три сервера, и настройте необходимые компоненты Windows на каждом, как описано в части 1 . Затем разверните клиентское приложение на сервере клиентских приложений, создайте очереди сообщений на сервере MSMQ и разверните сервис в IIS на сервере сервисных приложений. За исключением того факта, что поля отличаются, на этом этапе действительно нет никакой разницы с тем, что вы делали в сценарии с одним сервером.
Разрешить анонимным пользователям отправлять в очередь
Первое различие между сценарием с одним сервером и несколькими серверами состоит в том, что MSMQ обычно отклоняет неаутентифицированные сообщения от удаленных компьютеров. Когда вы используете для режима безопасности «Нет» (или «Сообщение») в NetMsmqBinding, все сообщения будут считаться отправленными притворным пользователем с именем ANONYMOUS LOGON. Таким образом, вам нужно установить ACL в очереди сообщений, чтобы предоставить учетной записи ANONYMOUS LOGON разрешение «Отправить сообщение». Этот шаг навсегда поставил меня в тупик — я назначил разрешения фактической учетной записи, под которой работало мое клиентское приложение, но все сообщения оказались в очереди недоставленных сообщений с сообщением «Отказано в доступе». Надеюсь, этот совет избавит вас от такой же боли!
Измените BindingInformation службы, чтобы он указывал на сервер MSMQ.
Помните, как нам нужно было настроить IIS с помощью appcmd.exe для прослушивания протокола MSMQ? Ну, одной из частей синтаксиса загадочной команды была bindingInformation = ‘localhost’. Значение атрибута bindingInformation варьируется для каждого протокола, но для net.msmq это относится к серверу, на котором размещены очереди, которые IIS должен прослушивать. В нашем многосерверном сценарии мы будем помещать наши очереди на отдельный сервер с именем msmqserver . Во-первых, давайте отключим привязку localhost, которую мы настроили в прошлый раз. Обратите внимание, что единственная разница в синтаксисе для добавления и удаления привязки заключается в использовании — + против — .
appcmd set site «Веб-сайт по умолчанию» —bindings. [protocol = ‘net.msmq’, bindingInformation = ‘localhost’]
Теперь давайте включим протокол net.msmq для нашего удаленного сервера msmqserver:
appcmd set site «Default Web Site» — + bindings. [protocol = ‘net.msmq’, bindingInformation = ‘msmqserver’]
Если вы не присоединены к домену, вот главный совет из примера активации MSMQ на MSDN : «Чтобы включить активацию на компьютере, присоединенном к рабочей группе, и служба активации, и рабочий процесс должны быть запущены с определенной учетной записью пользователя. (должно быть одинаковым для обоих), и очередь должна иметь списки ACL для конкретной учетной записи пользователя. «
Обновите адрес очереди в конфигурационных файлах
Надеемся, что последним шагом будет изменение адреса очереди в файлах конфигурации для вашего клиента и приложений-служб. Единственное изменение должно состоять в том, чтобы заменить localhost на msmqserver , что приведет к URI очереди, подобному net.msmq: //msmqserver/private/MsmqService/MsmqService.svc.
Включение транспортной безопасности
Теперь, когда все работает правильно на нескольких машинах, давайте начнем укреплять решение, включив Transport Security. NetMsmqBinding имеет четыре режима безопасности: Нет (который мы использовали до сих пор), Транспорт (который указывает, что мы должны использовать встроенные функции безопасности MSMQ), Сообщение (в котором WCF обеспечивает безопасность на уровне SOAP), и Оба (который сочетает в себе режимы транспорта и сообщения). В этом сценарии мы будем использовать транспортную безопасность, поскольку она позволяет администраторам использовать стандартные функции безопасности MSMQ. Самое главное, что это позволит нам заблокировать очередь, поэтому только учетная запись, на которой работает наш клиент, имеет право отправлять сообщения в очередь.
Включить интеграцию MSMQ Active Directory
Если вы еще этого не сделали, перейдите в раздел «Установка и удаление компонентов Windows» и включите интеграцию MSMQ Active Directory. Использование AD — это самый простой способ заставить Transport Security работать. Можно использовать Transport Security без AD, если вы используете пользовательские сертификаты, но я не буду обсуждать этот подход в этой статье (в основном потому, что я никогда не пробовал :-).
Настройте привязки WCF
Чтобы включить Transport Security, нам нужно настроить новую привязку WCF. (В качестве альтернативы вы можете просто изменить конфигурацию существующей привязки, но я хотел бы убедиться, что имя каждой привязки описывает, что она на самом деле делает). Транспорт является режимом безопасности по умолчанию для NetMsmqBinding, но во избежание путаницы я также хотел бы настроить это явно:
<netMsmqBinding> <binding name="MsmqBindingNonTransactionalTransportSecurity" exactlyOnce="false"> <security mode="Transport"/> </binding></netMsmqBinding>
Это должно входить в конфигурационные файлы вашего клиента и сервера. Конечно, вам также необходимо обновить конечные точки, чтобы использовать новую конфигурацию привязки MsmqBindingNonTransactionalTransportSecurity .
Настройка безопасности MSMQ
Этот шаг звучит просто, и в вашем случае это может быть. Однако в моей среде я обнаружил, что нужно было несколько хитростей (вероятно, в основном потому, что я использовал нестандартные учетные записи для своего клиента).
Простой бит — убедиться, что у учетной записи, на которой работает ваш клиент, есть разрешение на отправку в очередь сообщений. Если вы запускаете клиентское приложение под своей учетной записью, это, вероятно, уже установлено. После того, как вы проверили или установили ACL, попробуйте приложение и посмотрите, работает ли оно. Если так, поздравляю — все готово! Если нет, продолжайте читать.
Одна ошибка, которую мы увидели при попытке отправить в очередь: «Произошла ошибка при отправке в очередь: Нераспознанная ошибка -1072824273 (0xc00e002f). Убедитесь, что MSMQ установлен и работает. Если вы отправляете в локальную очередь, убедитесь, что существует очередь с требуемым режимом доступа и авторизацией. » Если вы это получите, это, вероятно, означает, что в Active Directory нет сертификата для вашей конкретной учетной записи пользователя на определенном сервере. Я не уверен, нужен ли вам сертификат для всех трех серверов в сценарии, но, вероятно, лучше быть в безопасности, чем потом сожалеть. Чтобы зарегистрировать сертификат, сделайте следующее:
- Войдите на соответствующий сервер, используя учетную запись пользователя, под которым вы будете отправлять сообщения.
- Откройте консоль управления компьютером (Windows Vista) или диспетчер сервера (Windows Server 2008).
- Найдите узел очереди сообщений, щелкните правой кнопкой мыши и выберите «Свойства».
- Нажмите на вкладку Сертификат пользователя.
- Нажмите кнопку «Зарегистрировать …», выберите соответствующий сертификат (обычно «ДОМЕН \ Имя пользователя, Имя сервера») и нажмите «Регистрация».
- Если ваш клиент работает в IIS 7 под учетной записью, отличной от NETWORK SERVICE, измените конфигурацию вашего пула приложений, чтобы загрузить профиль пользователя. По-видимому, это необходимо, чтобы позволить клиенту получить доступ к сертификату, необходимому для аутентификации.
После того, как вы это сделали, попробуйте еще раз — и снова, надеюсь, вы сделали. Еще одна хитрость, которую мы обнаружили, может оказаться необходимой — добавить учетную запись компьютера клиентского сервера приложений в группу домена AD, которая называется «Группа авторизации доступа Windows» — это описано в этой статье TechNet . Я не уверен в точных ситуациях, когда это необходимо, но если ничего не помогает, я бы предложил попробовать.
Если у вас по-прежнему возникают проблемы с установлением связи через боксы, последнее, что нужно проверить, — блокируется ли какой-либо трафик MSMQ брандмауэром. Я бы посоветовал временно отключить все брандмауэры через различные блоки, чтобы увидеть, если это проблема.
Надеемся, что теперь у вас будет безопасное, многосерверное развертывание вашего клиента WCF, сервера и очередей сообщений. В последней части мы пойдем еще дальше и переключимся на транзакционные очереди, чтобы ваши сообщения никогда не проходили.