Сбой аутентификации при использовании ARR для балансировки нагрузки внутренних веб-служб Lync 2013
Я использую Application Request Routing 3.0 в Windows Server 2012 R2 для балансировки нагрузки внутренних веб-служб в интерфейсном пуле Lync 2013; Я не использую его для обратного прокси-сервера внешних веб-сервисов (для этого есть отдельный обратный прокси-сервер), я использую его только в качестве балансировщика нагрузки, потому что у этого клиента нет другого доступного решения для балансировки нагрузки.
Я настроил DNS для направления всех URL-адресов внутренних веб-служб Lync на сервер ARR, я определил ферму серверов, включающую два интерфейсных сервера Lync в пуле, и настроил ARR для маршрутизации всех запросов HTTP и HTTPS. на эту ферму независимо от URL или имени хоста; веб-сайт по умолчанию в IIS на сервере ARR настроен только для анонимной аутентификации.
Запросы маршрутизируются правильно, но для всех аутентифицированных веб-сервисов Lync (которых много) аутентификация терпит неудачу.
Я определил, что проблема заключается в аутентификации Kerberos, и при быстром поиске в Google у многих людей возникли проблемы с аутентификацией при публикации аутентифицированных веб-сайтов / служб через ARR с аутентификацией Kerberos; Я попытался вручную отключить метод проверки подлинности "согласовать" в IIS на серверах Lync, оставив только "NTLM", и с этими настройками все работает нормально; это действительно показывает, что проблема на самом деле вызвана аутентификацией Kerberos. Однако изменение конфигурации IIS на серверах Lync полностью не поддерживается, и любое изменение вручную может быть сброшено при обновлении конфигурации или при установке обновления Lync, поэтому я не могу просто настроить IIS вручную таким образом.
Я ищу (поддерживаемый!) Способ заставить аутентификацию работать на внутренних веб-сервисах Lync, когда запросы направляются через сервер ARR.
Можно ли это сделать? Как?
2 ответа
После долгих попыток мы не нашли способа заставить аутентификацию Kerberos работать через ARR; В качестве обходного пути мы просто удалили сервер ARR из домена: это заставило его вообще пропустить проверку подлинности Kerberos, и все сразу заработало.
Я принимаю этот ответ, потому что он устранил проблему и позволил нам использовать ARR для балансировки нагрузки внутренних веб-служб Lync, но если / когда кто-то придет с ответом, который действительно может заставить аутентификацию Kerberos работать, я буду рад принять его,
Kerberos требует, чтобы SPN для учетной записи службы, на которой выполняется lync, был установлен для URL-адреса запроса, поступающего с сервера ARR. Вам потребуется установить имя участника-службы как для имени сервера, так и для внутреннего полного доменного имени, используя команду use, например:
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)".
Обсуждение делегации можно найти здесь.