В современных реалиях очень часто приходится в каком-то виде предоставлять удаленный доступ сотрудникам к сервисам, которые используются во внутреннем периметре сети компании. Тут есть несколько концептуально различающихся подхода – с использованием VPN и без использования VPN. Без использования VPN вы выборочно публикуете наружу нужные вам сервисы. Это может быть простой проброс портов (например, TCP/25 для сервиса входящей электронной почты), это может быть некий Reverse Proxy. Наример, Web Application Proxy от Microsoft, или KEMP LoadMaster, либо решения от других вендоров (F5, NGINX, Citrix NetScaler). Однако, для любого их приведенных решений требуется дополнительное оборудование, либо, как минимум, дополнительный виртуальный сервер. В отличии от Azure AD Application Proxy. Для его реализации нет необходимости в подготовке дополнительного сервера. Необходимый компонент можно установить на уже имеющийся сервер, но обо всем по порядку.
Зачем это нужно
Azure AD Application Proxy позволяет выполнить безопасную публикацию сервисов, которые используются внутри локальной сети вашей компании, во внешний мир. Для этого вам не нужно выполнять проброс сетевых портов или конфигурировать отдельный балансировщик или Reverse Proxy решение. Все, что вам нужно будет сделать – это выполнить установку небольшого компонента (Application Proxy Connector) и настроить соответствующее приложение в Azure AD. Обо всем этом мы поговорим в соответствующих разделах, в т.ч. поговорим и о требованиях.
Принцип работы Azure AD Application Proxy изображен на схеме ниже.
- Пользователь переходит по ссылке (endpoint), которая была настроена для доступа к приложению или сервису.
- Пользователь выполняет аутентификацию в Azure AD и получает токен, который будет использоваться в дальнейшем.
- С полученным токеном веб браузер пользователя обращается к сервису Applivation Proxy Service, который, в свою очередь, извлекает необходимую ему из токена.
- Далее запрос отправляется компоненту Application Proxy Connector.
- Если вы конфигурировали опцию единого входа (single sign-on), тогда Application Proxy Connector выполняет дополнительную аутентификацию в наземной Active Directory от имени пользователя.
- Application Proxy Connector отправляет запрос серверу приложений (для которого, собственно, и выполнялась настройку публикации).
- Полученный ответ отправляет назад клиенту (веб браузеру ПК пользователя) через Application Proxy Connector и Application Proxy Service соответственно.
Как видно из описания выше – Azure AD Application Proxy выполняет еще некоторую преаутентификацию. Забегая вперед, скажу, что можно предоставить доступ к приложению только определенным пользователям или группе пользователей. При необходимости можно настроить многофакторную аутентификацию.
Ссылка на соответствующий раздел официальной документации.
Основные компоненты
Основные компоненты системы приведены в таблице ниже.
| Компонент | Описание |
| Endpoint | Для пользователя этот компонент выглядит как ссылка для подключения к сервису. Например, https://docs.itproblog.ru. Конфигурируется при настройке приложения в Azure AD. |
| Azure AD | Облачный сервис службы каталогов. Выполняет аутентификацию, проверку разрешений и, при необходимости, многофакторную аутентификацию. |
| Application Proxy service | Облачный сервис, который взаимодействует с Azure AD. Передает токен пользователя компоненту Application Proxy Connector. |
| Application Proxy Connector | Агент, который устанавливается на сервер внутри сети компании. Использует только исходящие подключения. Никаких дополнительных портов открывать не нужно. Подробное описание этого компонента и требования к нему приведены в соответствующем разделе документации. |
| Active Directory | Наземная служба каталогов. Если настроена опция единого входа (single sign-on), то выполняются дополнительные шаги проверки аутентификации от имени пользователя. |
| Application Server | Публикуемое приложение. Как правило, это сервис, использующий HTTP или HTTPS для доступа к нему. |
Предварительные требования
Основные требования для использования сервиса Azure AD Application Proxy следующие:
- Наличие лицении Azure AD Premium (план P1 или P2). Такая лицензия включена, например, в такие планы: Microsoft 365 E3/E5, EMS (Enterprise Mobility Suite) E3/E5, Microsoft 365 F1/F3/F5. Также подписки Azure AD Premium P1 и P2 доступны в виде отдельного сервиса. Перечень основных тарифных планов и включаемых опцией (актуально на июль 2021).
- Для установки компонента Application Proxy Connector необходимы права локального администратора и администратора тенанта Azure AD.
- Все учетные записи пользователей Active Directory, которые будут использовать сервис должны быть синхронизованы в Azure AD.
Для установки агента необходимо, чтобы операционная система на сервере была Windows Server 2012 R2 или выше.
Для сервера, на котором будет установлен агент необходимо открыть порты TCP/80 и TCP/443 во внешний мир.
Более подробно все тонкости и детали предварительных требований доступны вот по этой ссылке.
Вы так же можете использовать свое собственное имя домена для публикуемого приложения. Для этого вам необходимо добавить домен в Azure AD и подтвердить право владения им (через регистрацию TXT записи), как указано вот тут.
Установка Azure Application Proxy Connector
Для того, чтобы можно было опубликовать приложение, которое работает внутри вашей локальной сети, предварительно необходимо скачать и установить Application Proxy Connector. Хотя бы на одном сервере.
Переходим по ссылке:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/AppProxyЕсли у вас совсем нет лицензий Azure Ad Premium (P1 или P2), то вы увидите следующее сообщение:
Если вы видите предупреждение о том, что использование коннектора еще не включено для вашего тенанта (Application Proxy is currently disabled for your tenant.), то такое возможно, если у вас еще не был установлен хотя бы один агент.
Нажимаем кнопку “Download connector service”.
Мастер загрузки попросит нас принять лицензионное соглашение. Читаем лицензионное соглашение и, при согласии, нажимаем “Accept tearm & Download”.
Загружаем файл с дистрибутивом и копируем его на тот сервер, где будет установлен агент. Запускаем файл от имени администратора.
На первой страница мастер установки читаем лицензионное соглашение и нажимаем кнопку “Install” (при согласии).
Затем мастер установки попросит нас указать учетные данные пользователя с ролью глобального администратора Azure AD, чтобы выполнить регистрацию агента. Указываем учетные данные.
Дожидаемся окончания процесса установки агента Azure AD Application Proxy Connector.
В случае успешного окончания процедуры установки вы увидите следующее окно.
Если в вашей организации используется прокси сервер, то для корректной работы агента необходимо указать настройки прокси сервера. Более подробная информация по этой настройке есть в документации.
Теперь если мы вернемся на страницу портала Azure AD с перечнем установленных агентов, то должны увидеть наш новый добавленный агент.
Для обеспечения отказоустойчивости рекомендуется выполнить настройку как минимум двух агентов Application Proxy.
Настройка приложения в Azure AD
После того, как мы выполнили установку как минимум одного агента все готово к настройке публикации нашего первого приложения.
Переходим в раздел “Entyerprise Application” на портале Azure AD.
https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/Нажимаем кнопку добавления нового приложения “New application”.
В появившемся окне выбираем пункт “Add an on-premises application”, как показано на скриншоте ниже.
На следующем шаге нам необходимо указать параметры нашего публикуемого приложения.
Необходимо заполнить как минимум следующие поля.
| Поле | Описание |
| Name | Имя приложения, которое будет отображаться на портале Azure AD. |
| Internal URL | URL приложения, которое используется внутри локальной сети. Именно на этот адрес агент Application Proxy и будет перенаправлять клиентов. |
| External URL | URL, по которому пользователи будут обращаться для доступа к сервису из внешнего мира. |
Для внешнего URL вы можете использовать как домены, предлагаемые Microsoft, так и использовать свой собственный домен, в т.ч. и для HTTPS. Более подробно использование собственных доменов приведено в соответствующем разделе документации.
В настройках нашего приложения переходим к разделу “Users and groups”.
Нажимаем кнопку “Add user/group” и указываем необходимых пользователей или группы.
Можно воспользоваться поиском по имени пользователя или группы.
После того, как мы указали всех необходимых пользователей и группы необходимо нажать кнопку Assign.
Проверка работы
Заключительным этапом выполним проверку нашего приложения. Перейдем по ссылку, которую мы указали в параметре External URL при настройке публикации приложения и на основе которого был сгенерирован итоговый URL.
https://scomweb.msappproxy.net/OperationsManagerAzure AD выполняет преаутентификацию учетной записи пользователя, т.е. сначала нам необходимо указать учетные данные для проверки подлинности в Azure AD.
Если публикация была настроена корректна, то мы будем перенаправлены на наше веб приложение. В нашем случае – это веб консоль System Center Operations Manager.
Теперь необходимо указать учетную запись для доступа к консоли Operations Manager и мы получим доступ непосредственно в консоль.
Как видно из текста выше – пароль нам потребуется указывать два раза. Один раз – это преаутентификация в Azure AD, второй раз – аутентификация непосредственно в самом публикуемом сервисе.
Можно сделать так, чтобы пароль запрашивался один раз, но для этого необходимо настроить SSO (Single sign-on) как на стороне публикуемого приложения, так и на строного Azure AD Application Proxy. Однако, это уже тема для отдлельной публикации 🙂
Заключение
В этой публикации мы рассмотрели один из альтернативных вариантов Reverse Proxy для публикации внутренних ресурсов во внешний мир – Azure AD Application Proxy. Мы рассмотрели основные требования для использования этого решения. Наглядно выполнили установку агента и настроили приложение. Затем мы посмотрели – как выглядит доступ к настроенной публикации приложения из внешнего мира.
Стоит отметить преимущество этого решения – минимальное вмешательство в конфигурацию вашей инфраструктур, возможность предварительной аутентификации и многофакторной аутентификации. С другой стороны, есть и особенности для реализации этого решения – наличие учетных записей пользователей в Azure AD, а также наличие лицензий Azure AD Premium P1 или P2.