В течение последних нескольких лет постепенно произошел заметный сдвиг в требованиях компаний к совместной работе. Поначалу реализация SharePoint была сугубо внутренним делом, но со временем начинал действовать веб-сайт, использовавшийся в закрытой корпоративной или общедоступной сети. В процессе работы, которую я выполнял последние 10 лет, решение двигаться в этом направлении связано с вертикальной организацией бизнеса. Например, финансовые компании приобретали SharePoint исключительно для внутреннего применения, а многие некоммерческие и общественные организации реализовывали полные веб-сайты, доступные в распределенной закрытой сети или общедоступной сети через внутреннюю сеть.

Но на сегодня это не имеет значения. Главное требование — обмен между внешними участниками, перекрестное взаимодействие между одной или несколькими компаниями.

Проблема в выполнении этих требований заключается в том, что не каждая компания может успешно справиться с такой задачей из-за стоимости инфраструктуры и развертывания. Расширение внутренней среды SharePoint за пределы корпоративного брандмауэра становится очень сложным решением, особенно когда речь идет о проверке подлинности учетных записей.

Компания Microsoft подготовила рекомендации по настройке внешнего доступа с использованием таких аппаратных средств, как обратные прокси-серверы, в сочетании с Active Directory или службами федерации Active Directory (ADFS) в качестве хранилища данных для проверки подлинности. Эти рекомендации доступны по адресам:

  • https://technet.microsoft.com/en-us/library/dn607304.aspx
  • https://blogs.msdn.microsoft.com/sambetts/2014/04/02/setting-up-a-reverse-proxy-for-sharepoint-with-tmg-server/

Я убежденный сторонник данного подхода, но от этого задача проверки подлинности тех внешних пользователей, которые не относятся к компании, не становится легкой. Учитывая, что SharePoint 2016 — стандартный по идее вариант локальной установки, более современный подход заключается в использовании каких-нибудь «облачных» служб, которые стали частью гибридной организации и могут быть задействованы, если у вас имеется клиент Office 365.

Чтобы этого добиться, необходимо выполнить следующие действия:

  1. Убедитесь, что пулы веб-приложений SharePoint работают с учетной записью службы.
  2. Настройте SharePoint для проверки подлинности Kerberos.
  3. Создайте имена субъекта-службы (SPN) и настройте ограниченное делегирование Kerberos.
  4. Опубликуйте SharePoint через прокси-сервер приложений Azure AD.
  5. Настройте сопоставления для альтернативного доступа в SharePoint для внешнего URL-адреса.
  6. Назначьте пользователей в прокси-сервере приложений Azure AD.

Вам не нужно беспокоиться о запуске пулов приложений с учетной записью службы. Если среда SharePoint не настроена должным образом, то перед вами могут возникнуть более серьезные проблемы.

Проверка подлинности Kerberos состоит из двух частей. Первая, более легкая, — обеспечить использование Kerberos веб-приложением в SharePoint.

  1. Откройте сайт центра администрирования SharePoint 2013 или 2016.
  2. В разделе Application Manage­ment («Управление приложениями») щелкните Manage web applica­tions («Управление веб-приложениями») и выберите сайт SharePoint (экран 1).
  3. Затем щелкните Authentication Providers («Поставщики проверки подлинности») на панели инструментов сверху.
  4. В окне Authentication Providers щелкните Default zone («Зона по умолчанию») для просмотра настроек.
  5. В окне Edit Authentication («Изменение параметров проверки подлинности») прокрутите вниз, чтобы увидеть типы проверки подлинности на основе утверждений и убедиться, что установлены флажки Enable Windows Authentication («Включить проверку подлинности Windows») и Integrated Windows Authentication («Встроенная проверка подлинности Windows»), а в раскрывающемся списке выбрано Negotiate (Kerberos), как показано на экране 2.
  6. Прокрутите окно до самого низа и нажмите кнопку Save («Сохранить»).

 

Выбор сайта SharePoint для настройки
Экран 1. Выбор сайта SharePoint для настройки

 

 

Настройка аутентификации веб-приложения
Экран 2. Настройка аутентификации веб-приложения

 

Для добавления имен субъекта-службы необходимо выполнить следующую команду:

setspn -S http/{SharePoint Site
   URL} DOMAIN\User

И конечно, следует изменить URL-адрес в соответствии с URL-адресом SharePoint и настроить учетную запись таким образом, чтобы она была учетной записью службы в вашем домене и на серверах SharePoint. Вы можете проверить, добавлено ли имя субъекта-службы, выполнив команду setspn с параметром -l

setspn -l DOMAIN\User

После того как имя субъекта-службы добавлено и проверка выполнена, необходимо настроить делегирование в Active Directory. Это делается следующим образом:

  1. Выполните регистрацию как администратор домена на контроллере домена и откройте средство Active Directory Users and Computers («Пользователи и компьютеры Active Directory»).
  2. Найдите компьютер, на котором выполняется соединитель. В данном случае это тот же сервер SharePoint.
  3. Дважды щелкните на имени компьютера и перейдите на вкладку Delegation («Делегирование»).
  4. Убедитесь, что в настройках делегирования задано Trust this computer for delegation to the specified services only («Доверять компьютеру делегирование только для указанных служб») и выбран параметр Use any authentication protocol («Использовать любой протокол проверки подлинности»), как показано на экране 3.
  5. Теперь нужно добавить созданное ранее имя субъекта-службы для учетной записи, нажав кнопку Add («Добавить»), а затем Users or Computers («Пользователи или компьютеры») и воспользовавшись учетной записью службы.
  6. В результате должен появиться список имен субъекта-службы. Остается добавить лишь имя, заданное ранее, а затем выбрать элемент и нажать кнопку OK.
  7. Нажмите OK повторно, чтобы сохранить изменения.

 

Проверка настроек делегирования
Экран 3. Проверка настроек делегирования

 

Осталось лишь задать значения на экранах прокси-сервера Azure Active Directory. Для этого:

  1. Выполните регистрацию на портале управления Azure https://manage.windowsazure.com и найдите своего клиента Azure AD.
  2. Выберите Applications («Прило­жения») и нажмите кнопку Add («Добавить») внизу.
  3. Выберите Publish and application that will be accessible from outside your network («Публикация приложения, которое будет доступно за пределами вашей сети»).
  4. В открывшемся диалоговом окне введите три параметра, как показано ниже, и щелкните флажок:
  • Name («Имя») — любое значение;
  • Internal URL («Внутренний URL-адрес») — внутренний URL-адрес HTTPS сайта SharePoint;
  • Pre-Authentication Method («Способ предварительной проверки подлинности») — выберите Azure Active Directory.

После того как приложение опубликовано, перейдите на вкладку Configure («Настройка»).

  1. Прокрутите вниз до элемента Translate URL in Headers («Перевод веб-страниц в заголовках») и установите значение No.
  2. Измените Internal Authentication Method («Метод внутренней проверки подлинности») на Windows Integrated («Встроенная проверка подлинности Windows»). Если ваш клиент Azure AD использует в «облаке» иное имя субъекта-службы, нежели локально, то обновите Delegated Login Identity («Делегированная идентификация для входа»).
  3. Присвойте Internal Application SPN («Внутреннее имя субъекта-службы приложения») установленное ранее значение.
  4. Опубликуйте сайт.

На данном этапе нужно установить сопоставления для альтернативного доступа, чтобы пакет мог быть загружен. Имейте в виду: то, что вы выполнили все эти операции, не означает, что сторонний адрес электронной почты, с которым вы хотите организовать взаимодействие, будет принят. Возникает проблема выбора решения, обеспечивающего настоящее внешнее взаимодействие. К счастью, с помощью Azure Active Directory можно предоставить возможность регистрации и доступ другим пользователям. Это объясняется тем, что Azure Active Directory поддерживает такой тип проверки подлинности.

В подобной ситуации, если бы у меня появилась насущная необходимость в совместной работе с внешними пользователями, я бы всерьез рассматривал возможность применения Office 365. Все готово к работе, и вы можете взаимодействовать с внешними пользователями, зная, что они смогут настроить свои учетные записи для регистрации в службе Office 365 и получить доступ только к тому контенту или сайтам, к которым вы разрешили обращение.

Дополнительные сведения об общем доступе для внешних пользователей можно найти здесь:

  • https://support.office.com/en-us/article/Share-sites-or-documents-with-people-outside-your-organization-80e49744-e30f-44db-8d51-16661b1d4232;
  • https://support.office.com/en-us/article/Manage-external-sharing-for-your-SharePoint-Online-environment-C8A462EB-0723-4B0B-8D0A-70FEAFE4BE85.

В целом идея совместной работы за брандмауэром существовала давно, но ее реализация всегда была затруднена из-за проверки подлинности. Благодаря Office 365 этот пробел восполнен, и отныне метод должен стать стандартом.

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

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