Я использую Application Request Routing 3.0 на Windows Server 2012 R2 для балансировки нагрузки внутренних веб-служб на интерфейсном пуле Lync 2013. Янетиспользуя его для обратного прокси-сервера внешних веб-сервисов (для этого есть отдельный обратный прокси-сервер), я использую его только как балансировщик нагрузки, поскольку у этого клиента нет другого доступного решения для балансировки нагрузки.
Я настроил DNS так, чтобы все внутренние URL-адреса веб-служб Lync указывались на сервер ARR, я определил ферму серверов, включающую два сервера Lync Front-End в пуле, и настроил ARR для маршрутизации всех HTTP- и HTTPS-запросов на эту ферму, независимо от URL-адреса или имени хоста; веб-сайт по умолчанию в IIS на сервере ARR настроен только для анонимной аутентификации.
Запросы маршрутизируются правильно, но для всех аутентифицированных веб-служб Lync (а их много) аутентификация завершается сбоем.
Я определил, что проблема заключается в аутентификации Kerberos, и быстрый поиск в Google обнаружил множество людей, у которых возникли проблемы с аутентификацией при публикации аутентифицированных веб-сайтов/служб через ARR с аутентификацией Kerberos; я пробовал вручную отключить метод аутентификации «negotiate» в IIS на серверах Lync, оставив только «NTLM», и с этими настройками все работает нормально; это действительно показывает, что проблема на самом деле вызвана аутентификацией Kerberos. Однако вмешательство в конфигурацию IIS на серверах Lync полностью не поддерживается, и любые ручные изменения, скорее всего, будут сброшены при обновлении конфигурации или установке обновления Lync, поэтому я не могу просто вручную настроить IIS таким образом.
Я ищу (поддерживаемый!) способ заставить работать аутентификацию на внутренних веб-службах Lync, когда запросы направляются через сервер ARR.
Можно ли это сделать? Как?
решение1
После долгих мучений мы не нашли способа заставить работать аутентификацию Kerberos через ARR; в качестве обходного пути мы просто удалили сервер ARR из домена: это заставило его вообще пропустить аутентификацию Kerberos, и все мгновенно заработало.
Я принимаю этот ответ, поскольку он устраняет проблему и позволяет нам использовать ARR для балансировки нагрузки внутренних веб-служб Lync, но если/когда кто-то предложит ответ, который действительно сможет заставить работать аутентификацию Kerberos, я буду рад его принять.
решение2
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 можно найти здесьздесь.
Кроме того, вам нужно будет изменить свойства Active Directory сервера ARR, чтобы он был доверенным для делегирования. Это устанавливается из свойств объекта сервера ARR в AD Users and Computers. На вкладке Делегирование установите переключатель "Trust this computer for delegate to any service (Kerberos only)".
Обсуждение делегирования можно найти здесьздесь.