Разворачиваем DirectAccess на базе Windows Server 2012 R2

В этой статье мы пошагово опишем процедуру разворачивания службы удаленного доступа Direct Access на самой свежей серверной платформе Microsoft — Windows Server 2012 R2. Вообще говоря, служба Direct Access предполагает несколько сценариев работы, мы попытаемся рассмотреть наиболее общий сценарий организации сервиса DirectAccess.

Прежде чем приступить, вкратце напомним о том, что такое служба DirectAccess. Компонент DirectAccess впервые была представлена Micrisoft в Windows Server 2008 R2 и предназначался для организации прозрачного доступа удаленных компьютеров ко внутренним ресурсам сети компании. При подключении через DA пользователь может полноценно пользоваться корпоративными и доменными сервисами, а сотрудники ИТ-поддержки управлять таким компьютеров и поддерживать его актуальном с точки зрения безопасности состоянии. По своей сути DirectAccess во многом напоминает традиционное VPN подключение к корпоративной сети. Рассмотрим основные отличия DirectAccess от VPN:

• Для установки соединения с помощью DirectAccess пользователю не нужно запускать VPN клиент – подключение осуществляется автоматически при наличия доступа в Интернет
• Для организации соединения между клиентом DA и сервером нужно открыть только 443 порт
• Компьютер пользователя обязательно должен находится в домене AD, а это значит что на него действуют все доменные групповые политики (конечно есть трюки, позволяющие запускать VPN до входа в Windows, но это обычно практически не практикуется)
• Канал связи между удаленным ПК и корпоративным шлюзом шифруется стойкими алгоритмами с использованием IPsec
• Возможно организовать двухфакторную аутентификацию с использованием системы одноразовых паролей

В чем же основные отличия версии DirectAccess в Windows Server 2012 / 2012 R2 от версии Windows 2008 R2. Основное отличие – снижение требований к смежной инфраструктуре. Так, например:

• Сервер DirectAccess теперь не обязательно должен быть пограничным, теперь он может находиться за NAT.
• В том случае, если в качестве удаленных клиентов используется Windows 8 Enterprise, разворачивать внутреннюю инфраструктуру PKI не обязательно (за аутентификацию клиентов будет отвечать Kerberos-прокси, расположенный на сервере DA)
• Не обязательно стало наличие IPv6 во внутренней сети организации
• Поддержка OTP (One Time Password) и NAP (Network Access Protection) без необходимости развёртывания UAG

Требования и инфраструктура, необходимы для развертывания DirectAccess на базе Windows Server 2012 R2

• Домен Active Directory и права администратора домена
• Выделенный (рекомендуется) сервер DA под управлением Windows Server 2012 R2, включенный в домен Windows. Сервер имеет 2 сетевые карты: одна находится во внутренней корпоративной сети, другая – в DMZ сети
• Выделенная DMZ подсеть
• Внешнее DNS имя (реальное или через DynDNS) или IP адрес, доступный из интернета, к которому будут подключатся клиенты DirectAccess
• Настроить перенаправление трафика с порта TCP 443 на адрес сервера DA
• Развернутая инфраструктура PKI для выпуска сертификатов. В certificate authority нужно опубликовать шаблон сертификата Web Server и разрешено его автоматическое получение (auto-enrollmen) (Если в качестве клиентов будут использоваться только Windows 8 — PKI не обязателен).
• В качестве клиентов могут выступать компьютеры с Windows 7 и Windows 8.x редакций Professional / Enterprise
• Группа AD, в которой будут состоять компьютеры, которым разрешено подключаться к сети через Direct Access (допустим, эта группа будет называться DirectAccessComputers)

Установка роли Remote Access

Запустим консоль Server Manager и с помощью мастера Add Roles and Features установим роль Remote Access.

В составе роли Remote Access нужно установить службу DirectAccess and VPN (RAS).

Все остальные зависимости оставляем по умолчанию.

Настройка службы Direct Access в Windows Server 2012 R2

После окончания установки службы Remote Access, откройте оснастку Tools -> Remote Access Management.

Запустится мастер настройки роли удаленного доступа. Укажем, что нам нужно установить только роль DA — Deploy DirectAccess only.

После этого должно открыться окно, в правой половине которого в графическом виде показаны четыре этапа (Step 1 – 4) настройки службы DA.

Первый этап (Step 1: Remote Clients).

Укажем, что мы разворачиваем полноценный DirectAccess сервер с возможностью доступа клиентов и их удаленного управления Deploy full DirectAccess for client access and remote management.

Далее, нажав кнопкуAdd нужно указать группы безопасности AD, в которой будут находиться учетные записи компьютеров, которым разрешено подключаться к корпоративной сети через Direct Access (в нашем примере это группа DirectAccessComputers).

Следующий шаг – нужно указать список внутренних сетевых имен или URL-адресов, с помощью которых клиент может проверить (Ping или HTTP запрос), что он подключен к корпоративной сети. Здесь же можно указать контактный email службы helpdesk и наименование подключения DirectAccess (так оно будет отображаться в сетевых подключениях на клиенте). В случае необходимости можно включить опцию Allow DirectAccess clients to use local name resolution, позволяющую разрешить клиенту использовать внутренние DNS-сервера компании (адреса DNS серверов могут получаться по DHCP).

Второй этап (Step 2: Remote Access Server)

Следующий шаг — настройка сервера Remote Access. Указываем, что наш сервер удаленного доступа представляет собой конфигурацию с двумя сетевыми картами — Behind an edge device (with two network adapters), одна их которых находится в корпоративной сети, а вторая подключена напрямую в Internet или DMZ-подсеть. Здесь же нужно указать внешнее DNS имя или IP адрес в Интернете (именно с этого адреса пробрасывается 443 порт на внешний интерфейс сервера DirectAccess), к которому должны подключаться клиенты DA.

Затем нужно указать какая сетевая карта будет считаться внутренней (Internal – LAN), а какая внешней (External – DMZ).

Свернем пока мастер настройки сервера Direct Access и сгенерируем сертификат сервера DA. Для этого создадим новую оснастку mmc, в которую добавим консоль Certificates, управляющую сертификатами локального компьютера (Computer Account)

В консоли управления сертификатами запросим новый персональный сертификат, щелкнув ПКМ по разделу Certificates (Local Computer) -> Personal -> Certificates и выбрав в меню All Tasks-> Request New Certificate

Запросим сертификат через политику Active Directory Enrollment Policy. Нас интересует сертификат на основе шаблона WebServers.

В настройках запроса нового сертификата на вкладке Subject заполним поля, идентифицирующие нашу компанию, а на вкладке Private Key укажем, что закрытый ключ сертификата можно экспортировать (Make private key exportable).

Сохраним изменения и запросим новый сертификат у CA.

Вернемся в окно настроек сервера DirectAccess и, нажав кнопку Browse, выберем сгенерированный сертификат.

На следующем шаге мастера выберем способ аутентификации клиентов Direct Access. Укажем, что используется аутентификация по логину и паролю AD (Active Directory credentials – username/password). Отметим чекбокс Use computer certificates (Использовать сертификаты компьютеров) и Use an intermediate certificate. Нажав кнопку Browse, нужно указать центр сертификации, который будет отвечать за выдачу сертификатов клиентов.

Третий этап (Step 3: Infrastructure Servers)

Третий этап – настройка инфраструктурных серверов. Нам будет предложено указать адрес сервера Network Location Server, находящегося внутри корпоративной сети. Network Location Server — это сервер, с помощью которого клиент может определить, что он находится во внутренней сети организации, т.е. не требуется использовать DA для подключения. NLS – сервером может быт любой внутренний веб-сервер (даже с дефолтной страничкой IIS), основное требование – сервер NLS не должен быть доступен снаружи корпоративной сети.

Далее укажем список DNS серверов для разрешения имен клиентами. Рекомендуется оставить опцию Use local name resolution if the name does not exist in DNS or DNS servers are unreachable when the client computer is on a private network (recommended).

Затем укажем DNS-суффиксы внутренних доменов в порядке приоритета их использования.

В окне настройки Management ничего указывать не будем.

Четвертый этап (Step 4: Application Servers)

Этап настройки серверов приложений. На этом этапе можно настроить дополнительную аутентификацию и шифрование трафика между внутренними серверами приложений и клиентами DA. Нам это не требуется, поэтому оставим опцию Do not extend authentication to application servers.

На этом мастер настройки роли Remote Access завершен, нам осталось сохранить изменения.

После окончания работы мастер создаст две новых групповых политик DirectAccess Client Settings и DirectAcess Server Settings, которые прикреплены к корню домена. Их можно оставить там, либо перелинковать на нужный OU.

Тестируем работу Direct Access на клиенте Windows 8

Чтобы протестировать работу Direct Access с клиента, добавим это компьютер (напомним, что это должен быть ПК с Windows 8.X Enterprise ) в группу DirecAccessCompurers, обновим на нем групповые политики (gpupdate /force).

Отключаем тесовую машину от корпоративной сети и подключаемся в интернету через Wi-Fi. Система автоматически подключается к корпоративной сети через DirectAccess, о чем свидетельствует статус Connected значка Workplace Connection (именно так мы назвали наше подключение при настройке сервера) в списке сетей.

Наличие подключения к сети через DirectAccess можно проверить с помощью PowerShell команды:

Get- DAConnectionStatus

Если она возвращает ConnectedRemotely, значит подключение DA к корпоративной сети