No direct access

Разворачиваем 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.

Читать еще: База данных 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, нужно указать центр сертификации, который будет отвечать за выдачу сертификатов клиентов.

Читать еще: Process all access

Третий этап (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 команды:

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

Что может дать DirectAccess пользователям Windows 7?

Удаленную схему работы можно считать одним из современных трендов. Достаточно часто специалисты, которые немного приболели, не вызывают врача и не берут больничный, а остаются на пару дней работать дома. Кроме того, многие менеджеры, находясь в командировке, тем не менее, должны читать корпоративную почту, писать отчеты и пр. Помимо всего прочего, некоторые компании по тем или иным причинам (желание работника, проживание его в другом городе, отсутствие места в офисе, нехватка финансов и т.п.) держат в штате «удаленных» сотрудников. Для эффективной работы им необходимо получить доступ к корпоративному серверу и возможность осуществлять «на расстоянии» все то, что они обычно делают в офисе: читать электронную почту, работать с «закрытыми» папками, формировать аналитические отчеты. При использовании рабочих станций под управлением Windows 7 и серверов с ОС Windows Server 2008 R2 такой доступ позволяет осуществить технология Direct Access.

Читать еще: Access для начинающих

Основное предназначение DirectAccess такое же, как у VPN, а именно — предоставление защищенного соединения с корпоративной сетью для удаленных пользователей, работающих через публичные сети (чаще всего — интернет). Тем не менее, в отличие от VPN, здесь вся процедура осуществляется в фоновом режиме, поэтому пользователю не придется вручную осуществлять вход после перезагрузки компьютера или при обрыве связи.

DirectAccess vs. VPN

Источник: Microsoft, 2009

С помощью DirectAccess устанавливается защищенное двунаправленное соединение с использованием протоколов IPv6 и IPSec. При этом IPSec позволяет применять для шифрования передаваемого трафика алгоритмы Triple Data Encryption Standard (3DES) или Advanced Encryption Standard (AES). Использование двух протоколов является еще одним преимуществом перед привычной VPN – это гарантирует доступ в сеть даже в том случае, когда провайдер по какой-либо причине заблокировал трафик IPsec.

Схема работы с DirectAccess достаточно проста: компьютер пользователя соединяется с сервером DirectAccess, который выступает в роли своеобразного шлюза для доступа к остальным корпоративным ресурсам. При этом клиент DirectAccess, являющийся частью Windows 7, устанавливает два соединения с использованием IPSec ESP (протокол безопасного закрытия содержания — Encapsulating Security Payload): IPsec ESP тоннель с использованием сертификата компьютера для обеспечения соединения с корпоративным DNS сервером и контроллером домена, который позволяет применять к компьютеру групповые политики до входа пользователя в ОС, и IPsec ESP тоннель с одновременным использованием сертификата компьютера и учетных данных пользователя для предоставления доступа к внутренним корпоративным ресурсам и приложениям.

При большом количестве внешних пользователей для серверов DirectAccess могут применяться технологии кластеризации и балансировки нагрузки.

Хотелось бы отметить еще одно преимущество DirectAccess перед VPN. При использовании данной технологии можно отделить «корпоративный» трафик от остального, предназначенного для внешних серверов. Это позволяет снизить нагрузку на корпоративные сервера, поскольку дает возможность перенаправить интернет-трафик в обход установленных защищенных соединений.