Продукт SharePoint существует уже достаточно давно, поэтому всем нам должно быть хорошо известно, как создавать веб-приложения, семейства сайтов и сами сайты. На практике мы должны успешно определять нужные адреса URL, наряду с любыми сопоставлениями, и настраивать использование сертификата SSL. Однако, потратив некоторое время на исследование сред SharePoint, я пришел к выводу, что знание способов установки и целей применения «сопоставления для альтернативного доступа» Alternate Access Mappings применяется более широко. Еще одна важная тема — мистическое семейство сайтов с именем узла, наряду с назначением сертификатов SSL для сайта.

Поэтому начнем с принципов «сопоставления для альтернативного доступа». Прежде всего рекомендую ознакомиться с материалами на эту тему: https://technet.microsoft.com/en-us/library/cc261814.aspx. Специалисты Microsoft описывают сопоставления для альтернативного доступа следующим образом: «Сопоставления для альтернативного доступа позволяют веб-приложению, которое получает запрос на внутренний адрес URL в одной из пяти зон, возвращать страницы, содержащие ссылки на общедоступный адрес URL для зоны. Вы можете связать веб-приложение, используя коллекцию сопоставлений между внутренними и общедоступными адресами URL. Внутренним называется адрес URL веб-запроса в том виде, в котором его получает SharePoint 2013. Общедоступным называется адрес URL, с помощью которого SharePoint форматирует ссылки, соответствующие запросам, сопоставленным одному из внутренних адресов URL в этой зоне, когда SharePoint возвращает ответ. Общедоступный адрес URL — базовый адрес, который SharePoint 2013 использует на возвращаемых страницах. Если внутренний адрес URL изменен системой обратного прокси-сервера, он может отличаться от общедоступного адреса URL».

Когда читаешь подобный текст, часто бывает трудно уловить смысл. Поэтому давайте разберем тему немного подробнее. Веб-приложения SharePoint могут размещаться в зоне. Зона, в сущности, представляет собой контейнер для адреса URL и процесса проверки подлинности, необходимых для вашего сайта. Веб-приложение может иметь несколько зон, которые могут содержать не только различные адреса URL, но и всевозможные способы проверки подлинности, хотя такой подход необязателен. На рисунке 1 показан сайт SharePoint с общедоступным адресом URL https://portal.sharepoint.com и внутренним адресом URL http://portal.sharepoint.com.

 

Сайт SharePoint с общедоступным адресом URL и внутренним адресом URL
Рисунок 1. Сайт SharePoint с общедоступным адресом URL и внутренним адресом URL

В чем состоят различия между общедоступным и внутренним адресами URL? Общедоступный адрес URL — это тот адрес, по которому любой пользователь может обратиться к сайту. Это могут быть особые категории пользователей, например действительно внешний пользователь или обычный пользователь сети. Внутренний адрес URL в данном случае служит для преобразования HTTP в HTTPS программной средой SharePoint. Назначение адреса URL в качестве общедоступного и внутреннего обеспечивает перенаправление.

Сайт SharePoint, в зависимости от потребностей, может иметь много адресов URL. Некоторые из них могут быть назначены одной и той же зоне, другие — отдельным узлам. Например, если у нас есть сайт http://www.sharepoint.com и его нужно изменить на https://www.sharepoint.com, а затем позаботиться о перенаправлении http://portal.sharepoint.com на тот же сайт, то мы создаем такие сопоставления в SharePoint, как в таблице 1.

 

Пример сопоставлений адресов

Масштабирование можно продолжить, если имеются другие адреса URL. Предположим, нам необходим доступный только изнутри адрес URL, такой как http://admin.sharepoint.com, а также требуется обеспечить работу и перенаправление http://intranet.sharepoint.com в https://intranet.sharepoint.com и разрешить протокол NTLM для адреса URL Admin и регистрацию на основе форм с использованием адреса URL внутренней корпоративной сети. Мы создаем такие сопоставления, как в таблице 2.

 

Сопоставления для внутренних адресов

Корректное назначение сопоставлений для альтернативного доступа поможет обеспечить работу SharePoint с каждого адреса URL с правильной проверкой подлинности. При неверном назначении сопоставлений возникает впечатление отказов SharePoint, поскольку наблюдается путаница с доступом к адресам URL. Слишком часто адреса URL добавляются ради обратной совместимости, но их добавляют как новые адреса URL в новых зонах, вместо того чтобы составлять продуманные планы. Например, их можно добавить так, как показано в таблице 3.

 

Пример ошибочной настройки сопоставлений

Такой метод работает, но это означает лишь то, что веб-приложение будет воспринимать каждый адрес URL как независимый и не связанный с остальными. В случае когда основной адрес URL должен быть http://one.sharepoint.com, другие адреса URL могут быть сопоставлены по-разному (см. таблицу 4). Данный подход позволит SharePoint выполнить перенаправление на новый адрес URL, но при этом поддерживать другие адреса URL как точку доступа к сайту.

 

Исправленные сопоставления

При использовании SSL-сертификатов SharePoint может выполнять внутреннее перенаправление, устанавливая общедоступный адрес URL в SSL, а затем адреса HTTP как внутренние для общедоступной зоны URL. SSL-сертификаты необходимо назначать внутри служб Internet Information Services (IIS), а также требуется определить для сайта сопоставления для альтернативного доступа. Без этих двух условий, даже если IIS ответит на запрос, SharePoint будет воспринимать адрес URL как неверный. Логическая архитектура строится на сопоставлениях «один к одному» от IIS к SharePoint, наряду с SSL-сертификатами и сопоставлениями для альтернативного доступа (см. рисунок 2).

 

Логическая архитектура использования сертификатов SSL
Рисунок 2. Логическая архитектура использования сертификатов SSL

Единственное исключение из этого правила — случай, когда используются семейства сайтов заголовка узла. В результате меняется структура, почти целиком зависящая от способа, применяемого SharePoint для распознавания заголовков узла для семейства сайтов (см. рисунок 3). Чтобы узнать больше об их работе, прочитайте статью по адресу: https://blogs.msdn.microsoft.com/kaevans/2012/03/27/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections/.

 

Использование семейства сайтов заголовка узла
Рисунок 3. Использование семейства сайтов заголовка узла

В целом понимание, как функционируют адреса URL и как применяется SSL наряду с семействами сайтов с именем узла, может заметно повлиять на работу конечного пользователя.

В заключение приведу список полезных ресурсов:

  • https://technet.microsoft.com/en-us/library/cc424952.aspx;
  • https://technet.microsoft.com/en-us/library/cc263208.aspx;
  • https://technet.microsoft.com/en-us/library/cc261814.aspx;
  • https://blogs.msdn.microsoft.com/sharepoint_strategery/2013/05/27/alternate-access-mappings-aams-explained/;
  • https://blogs.msdn.microsoft.com/voyage/2014/04/27/host-named-site-collections-in-sharepoint-2013/.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF