Координация URL-адресов с альтернативным сопоставлением доступа и DNS

  • Article

Исходная статья опубликована в среду 25 мая 2011 г.

Марк Аренд (Mark Arend), старший консультант, поднял ряд интересных вопросов о координации URL-адресов с альтернативным сопоставлением доступа и DNS:

  • Как настроить альтернативное сопоставление доступа для URL-адресов с одним компонентом имени, например https://fabrikam?
  • Как осуществляется координация доступа с балансировкой нагрузки с веб-приложениями, которые расширены путем использования нескольких зон, например https://partnerweb и https://remotepartnerweb.fabrikam.com?

Настройка альтернативного сопоставления доступа может оказаться довольно сложной задачей. Проведя некоторые исследования и проконсультировавшись с нашим дальновидным специалистом по тестированию Троем Старром (Troy Starr), мы вместе с Марком составили следующую схему, в которой представлена вся информация, необходимая для создания и изменения альтернативных сопоставлений доступа на основе традиционной версии проверки подлинности для примера проекта логической архитектуры.

Как вы могли заметить, URL-адреса с одним компонентом имени (например, https://teams) можно настроить для доступа в интрасеть.  Эти URL-адреса разрешаются клиентом путем присоединения DNS-суффикса клиента (например, fabrikam.com) и последующего выполнения подстановки DNS для имени с этим суффиксом.  Например, если клиентский компьютер в домене fabrikam.com запрашивает https://teams, компьютер отправляет DNS запрос для https://teams.fabrikam.com. 

Помимо настройки альтернативного сопоставления доступа, требуется также некоторая обработка DNS. Необходимо настроить DNS с записью A для каждого полного доменного имени. Запись A указывает на IP-адрес с балансировкой нагрузки для веб-серверов, на которых размещен сайт. В стандартной производственной среде серверы настроены с использованием статически назначаемых IP-адресов, а также статически назначаемых записей A в DNS. 

После получения виртуального IP-адреса сервера балансировки нагрузки, браузер клиента устанавливает соединение с интерфейсным веб-сервером в ферме, после чего отправляет HTTP-запрос с исходным URL-адресом с одним компонентом имени (https://teams).  Служба IIS и SharePoint распознают его как запрос в зону интрасети с учетом настроек, заданных в альтернативных сопоставлениях.  Если вместо этого пользователь запрашивает https://teams.fabrikam.com, выполняется тот же процесс, который отличается только тем, что служба IIS и SharePoint получает это полное доменное имя и, таким образом, распознает этот запрос для зоны по умолчанию.

В средах с несколькими доменами необходимо внести записи CNAME для DNS для доменов, в которых не размещены сайты. Например, если сетевая среда Fabrikam включает второй домен с именем europe.fabrikam.com, для этих сайтов вносятся записи CNAME в домене Europe. Для сайтов группы в интрасети (https://teams) группы, вызванные записью CNAME, добавляются в домен europe.fabrikam.com, ведущий на teams.fabrikam.com. В этом случае, если в уточняющие запросы DNS добавляется суффикс DNS, запрос https://teams из домена Europe выполнит уточняющий поиск DNS для teams.europe.fabrikam.com и будет направлен записью CNAME на teams.fabrikam.com.

После того как я узнал о способах разрешения URL-адресов браузером, я понял, что https://fabrikam — не самый лучший пример URL-адреса (https://fabrikam.fabrikam.com?). Соответственно, я обновил стандартную версию проверки подлинности для примера проекта логической архитектуры, используя URL-адрес https://intranet. Загрузить обновленную версию можно по адресу  Примеры проектов SharePoint Server 2010: корпоративный портал с традиционной проверкой подлинности или с проверкой подлинности на основе утверждений (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x419).

В заключение отмечу, что имеется ряд известных проблем, связанных с клиентами Kerberos и разрешением записей CNAME. Если среда содержит проверку подлинности Kerberos,  см. Известные проблемы конфигурации Kerberos (SharePoint Server 2010).

Это локализованная запись блога. Исходная статья находится по адресу Coordinating URLs with AAM and DNS