Если у вас есть какой-либо внутренний корпоративный ресурс, то рано или поздно руководство компании поставит вопрос о его публикации в интернете. Конечно вы будете возражать, что выставление ресурсов с конфиденциальной информацией в интернет не очень безопасно даже соблюдая известные меры предосторожности и защиты данных, но по большому счету это не будет иметь значение. Почему? Ответ прост: в век информации к ресурсам её содержащим предоставляются несколько иные требования, чем десятилетие назад – сотрудник компании должен иметь доступ к основным корпоративным инструментам из любой точки мира без задержки и каких-либо сложностей. В свою очередь перед вами как системным администратором стоит задача не только публикации ресурсов, но и их надлежащей защиты. Вот и передо мной встала задача публикации сервера Sharepoint 2013 в интернете.
Изначально у меня был Sharepoint Server 2013 и Microsoft Forefront TMG в качестве шлюза. Хорошо то, что Microsoft официально поддерживает сценарий публикации Sharepoint через TMG, к тому же такой вариант является более защищенным, т.к. TMG пропускает все запросы через себя, а не просто перенаправляет их на целевой сервер. Например, при распределенной атаке отказа в обслуживании первым “ляжет” именно шлюз, тогда как сервер Sharepoint останется невредимым, а это однозначно плюс.
В интернете достаточно много ресурсов, где по шагам расписано как и что надо делать, но проблема в том, что сам процесс публикации состоит из множества настроек как самого правила публикации и создания прослушивателя, так и изменения ряда настроек сервера Sharepoint. Однако в большинстве статей этот момент не учитывается, авторы почему-то заранее считают, что сервер Sharepoint сконфигурирован и показывать его настройки вообще не нужно. В итоге как бы я ни старался делать все по инструкциям, опубликовать сервер у меня не получалось и, надо сказать, не у меня одного. В конечном счете когда я все же все настроил, решил обязательно закрепить полученный опыт написанием в некотором будущем статьи.
Подробный порядок настроек я предоставлять не буду, ограничусь скриншотами и описаниями сконфигурированного сервера Sharepoint и правил шлюза.
Содержание
Сертификат
Поскольку речь идет о безопасном использовании сервера через интернет, то без сертификата обойтись не получится. Было решено заказать сертификат в официальном центре сертификации. Нужно отметить один момент – сертификат должен содержать несколько доменных имен, в том числе и внутренние. В нашем случае внешнее имя будет sharepoint.<домен_организации>.ru, внутренне имя – intranet.
Сертификат корневого центра должен находиться в сертификатах доверенных корневых центров сертификации как на сервере Sharepoint, так и на шлюзе.
Настроить сертификаты вы можете через консоль MMC, добавив оснастку “Сертификаты” (нужно выбрать учетную запись компьютера).
Импортировать сертификат на сервер TMG нужно обязательно с закрытым ключом, иначе этот сертификат вы выбрать в прослушивателе не сможете. Экспортируемый с закрытым ключом сертификат имеет расширение .pfx. Также этот сертификат должен быть в двух хранилищах сертификатов локальной учетной записи компьютера на TMG – “Личное” и “Доверенные корневые центры сертификации” и в обоих с закрытым ключом!
Поскольку мы используем разные внутренний и внешний домены, самое время заняться настройкой привязок публикуемого сайта. Для этого заходим в “Диспетчер служб IIS” на сервере Sharepoint, разворачиваем дерево сайтов и правой кнопкой нажимаем на том, который хотим опубликовать, далее нажимаем на “Изменить привязки”.
Нам необходимо две записи – одна будет сидеть на 80 порту и доступна только изнутри, а другая на 443 и отвечать она будет за возможность достучаться до сервера извне; эти записи на скриншоте ниже помечены цифрами 1 и 2 соответственно.
Также надо кликнуть два раза мышкой на второй записи и в открывшемся окне выбрать сертификат, который мы получили от центра сертификации.
Прослушиватель
Пришло время заняться созданием прослушивателя на сервере-шлюзе. В этом разделе я приведу скриншоты настроек созданного прослушивателя, какие-то настройки я опишу словами. Как и где можно создать этот прослушиватель администраторы TMG должны знать, тут ничего сложного нет.
На вкладке “общие” можно указать только имя и описание, тут можно вписать что угодно.
На вкладке “Сети” у вас должна быть отмечена сеть, с которой прослушиваются запросы. В нашем случае это будет внешняя сеть. Кроме того, если у вас несколько внешних адресов, нужно в настройках сети выставить прослушивание только одного адреса. Это даст вам возможность опубликовать на 443 порту и другом ip-адресе какой-либо иной внешний ресурс, например, OWA.
На вкладке “Подключения” активна только галочка “Включить подключения SSL (HTTPS) для данного порта”.
Вкладка “Сертификаты” отображает информацию о выбранных сертификатах. Если вы все сделали правильно, то импортированный на TMG сертификат при выборе должен светиться зеленым цветом.
Вкладка “Проверка подлинности” на скриншоте ниже.
На вкладке “Формы” все настройки по умолчанию.
На вкладке “Единый вход” все отключено.
Тут нас будут интересовать лишь несколько вкладок, в остальных мы все оставим по умолчанию. Суть правила публикации в том, что внешние запросы оно принимает по защищенному каналу на 443 порту, а потом перенаправляет их по 80 порту по внутреннему соединению. Учтите это, когда будете создавать и прослушиватель, и правило публикации.
Кстати, в настройках правила внизу есть одна интересная кнопка, которую никто никогда не видит и не пользуется – “Правило тестир.”. Нажмите её, чтобы протестировать правило, должно быть все зеленым цветом, как у меня:
Стратегия минимальной загрузки
Ни на одном ресурсе в интернете не написано внятно, что с включенной функцией стратегии минимальной загрузки публикация Sharepoint через TMG работать не будет. Как говорится, невероятно, но факт. На это я потратил практически неделю и заметил чисто случайно, когда снаружи попытался пройти на сайт по прямой ссылке без записи, убрав из полного пути кусок адреса “_layouts/15/start.aspx#/”. Логика проста – изнутри редирект работал и после мелькания этого “лэйаута” был переброс на нормальный адрес, снаружи такого не происходило, однако если вводить сразу прямой адрес, то все работает, просто придется из каждой строки адреса вручную убирать эту запись.
О том, что опубликованные сайты с включенной стратегией минимальной загрузки работать не будут, я нашел тут: “SharePoint 2013 – Introduction to the Minimal Download Strategy (MDS)“. Цитата:
“The MDS is not enabled on publishing sites and is (as I understand it) not compatible with publishing sites, there are a couple of reasons for this, continue to read for more information”.
На этом все. Кому интересно, ниже вы сможете найти ссылки на интересные источники. В этой статье я добился публикации web-сервиса на 443 порту, но обычно пользователи чисто интуитивно просто вбивают сайт в адресную строку и таким образом попадают на незащищенное соединение. Конечно можно вручную вбивать “https://”, но разве это удобно, учитывая, что редирект сделать полностью в наших силах? О том, как реализовать перенаправление портов в Microsoft Forefront TMG, можно прочитать в следующей статье “Forefront TMG. Перенаправление портов“.
Setting up a Reverse Proxy for SharePoint with TMG Server
Минимальная загрузка или редирект SharePoint страниц на _layouts start.aspx
Обеспечение максимальной отдачи от SharePoint 2013 при обновлении
SharePoint 2013 – Introduction to the Minimal Download Strategy (MDS)
