Сбои аутентификации, чтобы использование ARR загрузило Lync 2013 баланса внутренние веб-сервисы
Я использую Запрос приложения, Направляющий 3.0 на Windows Server 2012 R2 для загрузки, балансируют внутренние веб-сервисы на пуле фронтенда Lync 2013 года; я не использую его для инвертирования прокси внешние веб-сервисы (существует отдельный обратный прокси для того), я только использую его в качестве подсистемы балансировки нагрузки, потому что этот клиент не имеет никакое другое решение для выравнивания нагрузки в наличии.
Я настроил DNS для указания на весь Lync внутренние URL веб-сервисов на сервер ARR, я определил ферму сервера включая два сервера Фронтенда Lync в пуле, и я настроил ARR для маршрутизации всего HTTP и Запросов HTTPS к этой ферме, независимо от URL или имени хоста; веб-сайт по умолчанию в IIS на сервере ARR настроен только для анонимной аутентификации.
Запросы направляются правильно, но для всех аутентифицируемых веб-сервисов Lync (которые являются многими), аутентификация терпит полный провал.
Я решил, что проблема заключается в аутентификации Kerberos, и быстрый поиск Google нашел много людей, имеющих проблемы аутентификации при публикации аутентифицируемых веб-сайтов/сервисов через ARR с аутентификацией Kerberos; я попытался вручную отключить "согласовывать" метод аутентификации в IIS на серверах Lync, оставив только "NTLM", и с этим настройки, все хорошо работает; это действительно показывает, что проблема на самом деле вызывается аутентификацией Kerberos. Однако переделывание конфигурации IIS на серверах Lync полностью не поддерживается, и любое ручное изменение, вероятно, будет сброшено, когда обновление конфигурации произойдет, или обновление Lync установлено, таким образом я не могу только вручную настроить IIS этот путь.
Я ищу (поддерживаемый!) способ заставить аутентификацию работать над внутренними веб-сервисами Lync, когда запросы направляются через сервер ARR.
Это может быть сделано? Как?
После долгих усилий мы не нашли способа заставить аутентификацию Kerberos работать через ARR; в качестве обходного пути мы просто удалили сервер ARR из домена: это заставило его полностью пропустить аутентификацию Kerberos, и все начало работать мгновенно.
Я принимаю этот ответ, потому что он устранил проблему и позволил нам использовать ARR для загрузки сбалансировать внутренние веб-службы Lync, но если / когда кто-то предложит ответ, который действительно может заставить аутентификацию Kerberos работать, я буду рад его принять.
Kerberos требует, чтобы SPN для учетной записи службы, на которой запущен lync, был установлен для URL-адреса запроса, поступающего с вашего сервера ARR. Вам нужно будет установить SPN как для имени сервера, так и для внутреннего FQDN, используя такую команду, как:
setspn -S http/<servername> domain.com\<Svc_Acct>
setspn -S http/<servername>.domain.com domain.com\<Svc_Acct>
Очень хорошее резюме SPN можно найти здесь .
Кроме того, вы потребуется изменить свойства активного каталога сервера ARR, чтобы он стал доверенным для делегирования. Это устанавливается в свойствах объекта сервера ARR в AD Users and Computers. На вкладке «Делегирование» установите переключатель «Доверять этому компьютеру для делегирования любой службе (только Kerberos)».
Обсуждение делегирования можно найти здесь .