Я использую 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.
Это можно сделать? Как?
После долгой борьбы мы не нашли способа заставить аутентификацию 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)».
Обсуждение делегирования можно найти Вот.